JP2003330964A - データベース・システム - Google Patents
データベース・システムInfo
- Publication number
- JP2003330964A JP2003330964A JP2003100031A JP2003100031A JP2003330964A JP 2003330964 A JP2003330964 A JP 2003330964A JP 2003100031 A JP2003100031 A JP 2003100031A JP 2003100031 A JP2003100031 A JP 2003100031A JP 2003330964 A JP2003330964 A JP 2003330964A
- Authority
- JP
- Japan
- Prior art keywords
- block
- index
- storage device
- program storage
- processing
- 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.)
- Granted
Links
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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
-
- 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/953—Organization of data
- Y10S707/954—Relational
-
- 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/953—Organization of data
- Y10S707/957—Multidimensional
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 リレーショナル・データベース管理システム
において、効率的な処理と保守を行なうことのできる多
次元クラスタ化表を提供する。 【解決手段】 多次元クラスタ化表は、少なくとも１つ
の独立した次元すなわちクラスタ化キーで同時にクラス
タ化し、ディスク上のブロックすなわちページに物理的
に編成した表である。このような多次元クラスタ化表を
作成するには、当該多次元クラスタ化表のデータをクラ
スタ化する際に依拠する次元として少なくとも１つのキ
ーを特定する。各次元は少なくとも１つの列から成る。
さらに、多次元クラスタ化表とともに使用する効率的な
照会処理手法と保守手法も提供する。
において、効率的な処理と保守を行なうことのできる多
次元クラスタ化表を提供する。 【解決手段】 多次元クラスタ化表は、少なくとも１つ
の独立した次元すなわちクラスタ化キーで同時にクラス
タ化し、ディスク上のブロックすなわちページに物理的
に編成した表である。このような多次元クラスタ化表を
作成するには、当該多次元クラスタ化表のデータをクラ
スタ化する際に依拠する次元として少なくとも１つのキ
ーを特定する。各次元は少なくとも１つの列から成る。
さらに、多次元クラスタ化表とともに使用する効率的な
照会処理手法と保守手法も提供する。
Description
【０００１】
【発明の属する技術分野】本発明は、一般にデータベー
ス・システムに関し、特にリレーショナル・データベー
スにおいて多次元ディスク・クラスタリングを実現する
手法、ならびにリレーショナル・データベースに格納さ
れた情報に対する多次元ディスク・クラスタリングを用
いた効率的なアクセス手法および保守手法に関する。
（クラスタリング〔クラスタ化〕とは属性が同じものを
複数個集めて１つのものにすることである。）
ス・システムに関し、特にリレーショナル・データベー
スにおいて多次元ディスク・クラスタリングを実現する
手法、ならびにリレーショナル・データベースに格納さ
れた情報に対する多次元ディスク・クラスタリングを用
いた効率的なアクセス手法および保守手法に関する。
（クラスタリング〔クラスタ化〕とは属性が同じものを
複数個集めて１つのものにすることである。）
【０００２】
【従来の技術】収益性を改善するために、ほとんどすべ
てのビジネス主体がデータウェアハウスを用いてビジネ
ス・インテリジェンスを獲得することに関心を抱いてい
る。技術世界で広く認識されているところによれば、大
部分のデータウェアハウスは多次元態様で編成されてい
る。ラルフ・キンボールら著『データウェアハウス・ツ
ールキット：次元データウェアハウスを構築するための
実戦手法』（Ralph Kimball, et al., The Data Wareho
use Toolkit: Practical Techniques for Building Dim
ensional Data Warehoses, John Wiley & Sons, ISBN:
0471153370, 1996）には、多次元スキーマを用いてデー
タウェアハウスをモデル化する方法が記載されている。
てのビジネス主体がデータウェアハウスを用いてビジネ
ス・インテリジェンスを獲得することに関心を抱いてい
る。技術世界で広く認識されているところによれば、大
部分のデータウェアハウスは多次元態様で編成されてい
る。ラルフ・キンボールら著『データウェアハウス・ツ
ールキット：次元データウェアハウスを構築するための
実戦手法』（Ralph Kimball, et al., The Data Wareho
use Toolkit: Practical Techniques for Building Dim
ensional Data Warehoses, John Wiley & Sons, ISBN:
0471153370, 1996）には、多次元スキーマを用いてデー
タウェアハウスをモデル化する方法が記載されている。
【０００３】比較的小規模のデータウェアハウスの構築
には相変わらず、多くのＯＬＡＰ（online analytical
processing: 多次元分析）システムで多次元配列設計が
用いられている。しかし、この多次元配列構造は１００
ギガバイトを超える記憶容量を必要とするような大規模
データウェアハウス用にうまく拡張することができな
い。このような大規模データウェアハウスはいまだにリ
レーショナル・データベース・モデルを用いて実装され
ている。既存のリレーショナル・データベースも何らか
のクラスタ化とデータ区分化を備えているけれども、そ
れらの手法は多次元データをサポートするのには十分で
ない。
には相変わらず、多くのＯＬＡＰ（online analytical
processing: 多次元分析）システムで多次元配列設計が
用いられている。しかし、この多次元配列構造は１００
ギガバイトを超える記憶容量を必要とするような大規模
データウェアハウス用にうまく拡張することができな
い。このような大規模データウェアハウスはいまだにリ
レーショナル・データベース・モデルを用いて実装され
ている。既存のリレーショナル・データベースも何らか
のクラスタ化とデータ区分化を備えているけれども、そ
れらの手法は多次元データをサポートするのには十分で
ない。
【０００４】ＯＬＡＰシステムは多くの次元あるいはす
べての次元を用いてデータを編成しようとするものであ
る。効率性の観点から、概念的多次元配列は実際には多
層構造によって実装されている。次元は各次元値に対し
て予期されるエントリ数に基づいて密な集合と粗な集合
に分けられる。密な次元は多次元配列として実装され、
粗な次元は各副配列を指示するのに使われる。アール
（Earle)の米国特許第５３５９７２４号にはそのような
手法が記載されている。この構成でもまだ非効率であ
る。というのは、密な次元は部分的にしか利用されてい
ないからである。たとえば、研究報告によれば、実世界
のデータでは密な配列は通常約２０％しか占有されてい
ない。
べての次元を用いてデータを編成しようとするものであ
る。効率性の観点から、概念的多次元配列は実際には多
層構造によって実装されている。次元は各次元値に対し
て予期されるエントリ数に基づいて密な集合と粗な集合
に分けられる。密な次元は多次元配列として実装され、
粗な次元は各副配列を指示するのに使われる。アール
（Earle)の米国特許第５３５９７２４号にはそのような
手法が記載されている。この構成でもまだ非効率であ
る。というのは、密な次元は部分的にしか利用されてい
ないからである。たとえば、研究報告によれば、実世界
のデータでは密な配列は通常約２０％しか占有されてい
ない。
【０００５】空間データベースや地理情報システムで
は、２次元あるいは３次元のデータ・モデルを用いてい
る。空間データを編成したり索引付けしたりするデータ
構造や方法が数多く提案されている。たとえば、Ｒ−Ｔ
ｒｅｅ、ＱｕａｄＴｒｅｅ、Ｇｒｉｄ Ｆｉｌｅなどで
ある。これらの索引付け構造のうちにはリレーショナル
・データベース管理システム（ＲＤＢＭＳ）の拡張とし
て実装されているものもあるが、データウェアハウスな
どの実装で必要な保守と照会処理の要件を満たしている
とは考えられていない。さらに、これらのシステムで
は、２次元あるいは３次元のデータを効率的にクラスタ
化する手法は考慮されていない。
は、２次元あるいは３次元のデータ・モデルを用いてい
る。空間データを編成したり索引付けしたりするデータ
構造や方法が数多く提案されている。たとえば、Ｒ−Ｔ
ｒｅｅ、ＱｕａｄＴｒｅｅ、Ｇｒｉｄ Ｆｉｌｅなどで
ある。これらの索引付け構造のうちにはリレーショナル
・データベース管理システム（ＲＤＢＭＳ）の拡張とし
て実装されているものもあるが、データウェアハウスな
どの実装で必要な保守と照会処理の要件を満たしている
とは考えられていない。さらに、これらのシステムで
は、２次元あるいは３次元のデータを効率的にクラスタ
化する手法は考慮されていない。
【０００６】
【課題を解決するための手段】リレーショナル・データ
ベース管理システムにおいて、少なくとも１つの次元に
よる表のクラスタリングを保守する効率的なスペース管
理手法を開示する。さらに、これらの表とともに使用す
る効率的な照会処理手法と保守手法も提供する。
ベース管理システムにおいて、少なくとも１つの次元に
よる表のクラスタリングを保守する効率的なスペース管
理手法を開示する。さらに、これらの表とともに使用す
る効率的な照会処理手法と保守手法も提供する。
【０００７】本発明の一側面により、リレーショナル・
データベースにおいてクラスタ化されたデータを効率的
に保守する方法を提供する。この方法は表定義パラメー
タを用いてリレーショナル・データベースの表の次元を
特定するステップを備えている。上記表はデータから成
るブロックを用いて各次元にクラスタ化されている。上
記表の各次元ごとにブロック索引を作成する。本発明の
別の側面によると、ブロックは連続記憶スペースに情報
を格納している。本発明の別の側面によると、各ブロッ
ク索引はブロックＩＤのリストに関連付けられた少なく
とも１つのキーを備えている。本発明の別の側面による
と、上記表の次元は上記表の少なくとも１つの列に関連
付けられている。本発明の別の側面によると、上記表定
義パラメータは表作成ステートメントまたは表変更ステ
ートメントに関連付けられている。本発明の別の側面に
よると、上記表は多次元表である。本発明の別の側面に
よると、この多次元表はたとえばデータウェアハウス用
の典型的な用途情報をモデル化するのに用いる。しかし
ながら、認識すべき点を挙げると、上記表は他の様々な
目的に用いることができる。
データベースにおいてクラスタ化されたデータを効率的
に保守する方法を提供する。この方法は表定義パラメー
タを用いてリレーショナル・データベースの表の次元を
特定するステップを備えている。上記表はデータから成
るブロックを用いて各次元にクラスタ化されている。上
記表の各次元ごとにブロック索引を作成する。本発明の
別の側面によると、ブロックは連続記憶スペースに情報
を格納している。本発明の別の側面によると、各ブロッ
ク索引はブロックＩＤのリストに関連付けられた少なく
とも１つのキーを備えている。本発明の別の側面による
と、上記表の次元は上記表の少なくとも１つの列に関連
付けられている。本発明の別の側面によると、上記表定
義パラメータは表作成ステートメントまたは表変更ステ
ートメントに関連付けられている。本発明の別の側面に
よると、上記表は多次元表である。本発明の別の側面に
よると、この多次元表はたとえばデータウェアハウス用
の典型的な用途情報をモデル化するのに用いる。しかし
ながら、認識すべき点を挙げると、上記表は他の様々な
目的に用いることができる。
【０００８】本発明のさらに別の側面によると、上記方
法はさらに複合次元索引を作成するステップを備えてい
る。本発明のさらに別の側面によると、上記複合次元索
引は自動的に作成する。本発明の一側面によると、上記
複合次元索引は複合キーのリストを備えており、各複合
キーは多次元表のセルに関連付けられているとともに、
当該セル用のブロックＩＤを少なくとも１つ有してい
る。
法はさらに複合次元索引を作成するステップを備えてい
る。本発明のさらに別の側面によると、上記複合次元索
引は自動的に作成する。本発明の一側面によると、上記
複合次元索引は複合キーのリストを備えており、各複合
キーは多次元表のセルに関連付けられているとともに、
当該セル用のブロックＩＤを少なくとも１つ有してい
る。
【０００９】本発明のさらに別の側面によると、上記方
法はさらに上記表用のビット・マップを作成するステッ
プを備えている。上記ビット・マップの各要素は上記表
に関連付けられたブロックの現在の状態に関連付けられ
ている。本発明の別の側面によると、各ブロックは状態
情報の複製を備えている。本発明の別の側面によると、
上記ビット・マップは、たとえば元のビット・マップが
破損したり使用できなくなったりしたときに、上記状態
情報の複製を用いて作成する。
法はさらに上記表用のビット・マップを作成するステッ
プを備えている。上記ビット・マップの各要素は上記表
に関連付けられたブロックの現在の状態に関連付けられ
ている。本発明の別の側面によると、各ブロックは状態
情報の複製を備えている。本発明の別の側面によると、
上記ビット・マップは、たとえば元のビット・マップが
破損したり使用できなくなったりしたときに、上記状態
情報の複製を用いて作成する。
【００１０】本発明のさらに別の側面によると、上記方
法はさらに上記表に格納されている情報を求める照会を
処理するステップを備えている。本発明のさらに別の側
面によると、照会を処理するステップはさらに、個々の
ブロック索引または複合索引の情報を用いてブロックＩ
Ｄのリストを取得するステップと、上記表のブロックを
スキャンしてレコードを探し出すステップとを備えてい
る。本発明の別の側面によると、照会を処理するステッ
プは、上記表全体をスキャンするステップと、レコード
基準索引を用いてレコードを探し出すステップとを備え
ている。本発明の別の側面によると、上記方法はさらに
索引ＡＮＤを行なうステップを備えている。本発明の別
の側面によると、上記方法はさらに索引ＯＲを行なうス
テップを備えている。本発明の別の側面によると、上記
方法はコスト・モデルに基づいて照会計画を作成するス
テップを備えている。
法はさらに上記表に格納されている情報を求める照会を
処理するステップを備えている。本発明のさらに別の側
面によると、照会を処理するステップはさらに、個々の
ブロック索引または複合索引の情報を用いてブロックＩ
Ｄのリストを取得するステップと、上記表のブロックを
スキャンしてレコードを探し出すステップとを備えてい
る。本発明の別の側面によると、照会を処理するステッ
プは、上記表全体をスキャンするステップと、レコード
基準索引を用いてレコードを探し出すステップとを備え
ている。本発明の別の側面によると、上記方法はさらに
索引ＡＮＤを行なうステップを備えている。本発明の別
の側面によると、上記方法はさらに索引ＯＲを行なうス
テップを備えている。本発明の別の側面によると、上記
方法はコスト・モデルに基づいて照会計画を作成するス
テップを備えている。
【００１１】本発明のさらに別の側面によると、上記方
法はさらに保守要求を処理するステップを備えている。
本発明の別の側面によると、この保守要求にはロード、
データベースの再編成、レコードの挿入、レコードの削
除、パージ、および更新がある。本発明の別の側面によ
ると、上記保守操作を実行したあとであってもクラスタ
リングは維持される。
法はさらに保守要求を処理するステップを備えている。
本発明の別の側面によると、この保守要求にはロード、
データベースの再編成、レコードの挿入、レコードの削
除、パージ、および更新がある。本発明の別の側面によ
ると、上記保守操作を実行したあとであってもクラスタ
リングは維持される。
【００１２】本発明のさらに別の側面によると、ロード
操作または挿入操作は、上記表に関連付けられたブロッ
クを１つ使用するステップ、または、（空〔から〕のス
ペースがない場合に）新たなブロックを割り当てるステ
ップを備えている。本発明の別の側面によると、保守操
作が再編成、削除、またはパージである場合にはスペー
スを再利用する。
操作または挿入操作は、上記表に関連付けられたブロッ
クを１つ使用するステップ、または、（空〔から〕のス
ペースがない場合に）新たなブロックを割り当てるステ
ップを備えている。本発明の別の側面によると、保守操
作が再編成、削除、またはパージである場合にはスペー
スを再利用する。
【００１３】本発明のこれらの側面および他の側面、特
徴、ならびに利点は、次に示す添付図面とともに読まれ
るべき好適な実施形態の詳細な説明によって明らかにな
る。
徴、ならびに利点は、次に示す添付図面とともに読まれ
るべき好適な実施形態の詳細な説明によって明らかにな
る。
【００１４】
【発明の実施の形態】まず、リレーショナル・データベ
ース管理システム（ＲＤＢＭＳ）を用いた、本発明に係
る多次元ディスク・クラスタリング用の環境を図１の文
脈で説明する。システム１００はメモリ１０１に接続さ
れたプロセッサ１０２、少なくとも１つの入出力（Ｉ／
Ｏ）装置１０４、およびＲＤＢＭＳ１０３を備えてい
る。プロセッサ１０２は本発明に係る方法を実装しうる
という点を認識すべきである。あるいは、ＲＤＢＭＳ１
０３が自分用のプロセッサ、メモリ、およびＩ／Ｏ装置
から成る構成（図示せず）を備えて本発明に係る方法を
実装してもよい。この構成では、たとえばサーバ・プラ
ットフォームにＲＤＢＭＳ１０３を常駐させ、プロセッ
サ１０２、メモリ１０１、およびＩ／Ｏ装置１０４をク
ライアント・システム中のプロセッサ１０２に付随させ
てもよい。無論、当業者が容易に認識しうるように、本
発明の本旨と範囲のうちでＲＤＢＭＳ１０３を用いて照
会を処理しうるように適合した構成は他にも数多くあ
る。
ース管理システム（ＲＤＢＭＳ）を用いた、本発明に係
る多次元ディスク・クラスタリング用の環境を図１の文
脈で説明する。システム１００はメモリ１０１に接続さ
れたプロセッサ１０２、少なくとも１つの入出力（Ｉ／
Ｏ）装置１０４、およびＲＤＢＭＳ１０３を備えてい
る。プロセッサ１０２は本発明に係る方法を実装しうる
という点を認識すべきである。あるいは、ＲＤＢＭＳ１
０３が自分用のプロセッサ、メモリ、およびＩ／Ｏ装置
から成る構成（図示せず）を備えて本発明に係る方法を
実装してもよい。この構成では、たとえばサーバ・プラ
ットフォームにＲＤＢＭＳ１０３を常駐させ、プロセッ
サ１０２、メモリ１０１、およびＩ／Ｏ装置１０４をク
ライアント・システム中のプロセッサ１０２に付随させ
てもよい。無論、当業者が容易に認識しうるように、本
発明の本旨と範囲のうちでＲＤＢＭＳ１０３を用いて照
会を処理しうるように適合した構成は他にも数多くあ
る。
【００１５】メモリ１０１はたとえばプロセッサ１０２
が自分が使用した情報を格納する際に使用する。Ｉ／Ｏ
装置１０４にはキーボード、マウス、および／または、
ユーザが照会および／または他のデータをシステム１０
０に入力するのを可能にする他の任意のデータ入力装置
がある。（「Ａおよび／またはＢ」は「ＡおよびＢ、
Ａ、またはＢ」を表わす。）Ｉ／Ｏ装置１０４にはディ
スプレイ、プリンタ、および／または、照会に付随する
結果および／または他のプロセッサ動作をユーザが閲覧
（観察）するのを可能にする他の任意の出力装置があ
る。ＲＤＢＭＳ１０３はＳＱＬ（構造化照会言語）コマ
ンド（あるいは他の種類の照会）を処理するシステム・
ソフトウェア（たとえば図２に示すようにもの）を備え
ている。上記処理には、たとえばＳＱＬコマンド（ある
いは他の種類の照会）を最適化すること、それらを実行
してプロセッサ１０２に戻された情報を取得することな
どがある。理解すべき点を挙げると、ＲＤＢＭＳ１０３
に付随する構造化データは複数の行と列を備えた個々の
表中に編成されている。次に動作を説明する。普通の構
成では、Ｉ／Ｏ装置１０４として標準のコンピュータ・
キーボードおよび／またはポインティング・デバイスな
どを使用しているエンドユーザが特定のＳＱＬコマンド
を入力する（あるいは特定のＳＱＬコマンドを生成させ
る）。次いで、プロセッサ１０２がＩ／Ｏ装置１０４か
らこのコマンドを受け取ったのち、それをＲＤＢＭＳ１
０３に送る。次いで、ＲＤＢＭＳ１０３は上記ＳＱＬコ
マンドを解析し、解析結果を最適化し、それをＲＤＢＭ
Ｓ自身が内蔵している情報に対して実行する。次いで、
ＲＤＢＭＳ１０３は結果表をプロセッサ１０２に送り返
す。プロセッサ１０２は当該結果表をＩ／Ｏ装置１０４
を使用しているエンドユーザに表示する。しかしながら
認識すべき点を挙げると、ＲＤＢＭＳ１０３と対話する
方法はこれ以外にも多数ある。たとえば、バッチ・モー
ドで実行しているコンピュータ・プログラムは、ユーザ
の直接的な対話を必要とせずにＲＤＢＭＳ１０３と対話
することができる。
が自分が使用した情報を格納する際に使用する。Ｉ／Ｏ
装置１０４にはキーボード、マウス、および／または、
ユーザが照会および／または他のデータをシステム１０
０に入力するのを可能にする他の任意のデータ入力装置
がある。（「Ａおよび／またはＢ」は「ＡおよびＢ、
Ａ、またはＢ」を表わす。）Ｉ／Ｏ装置１０４にはディ
スプレイ、プリンタ、および／または、照会に付随する
結果および／または他のプロセッサ動作をユーザが閲覧
（観察）するのを可能にする他の任意の出力装置があ
る。ＲＤＢＭＳ１０３はＳＱＬ（構造化照会言語）コマ
ンド（あるいは他の種類の照会）を処理するシステム・
ソフトウェア（たとえば図２に示すようにもの）を備え
ている。上記処理には、たとえばＳＱＬコマンド（ある
いは他の種類の照会）を最適化すること、それらを実行
してプロセッサ１０２に戻された情報を取得することな
どがある。理解すべき点を挙げると、ＲＤＢＭＳ１０３
に付随する構造化データは複数の行と列を備えた個々の
表中に編成されている。次に動作を説明する。普通の構
成では、Ｉ／Ｏ装置１０４として標準のコンピュータ・
キーボードおよび／またはポインティング・デバイスな
どを使用しているエンドユーザが特定のＳＱＬコマンド
を入力する（あるいは特定のＳＱＬコマンドを生成させ
る）。次いで、プロセッサ１０２がＩ／Ｏ装置１０４か
らこのコマンドを受け取ったのち、それをＲＤＢＭＳ１
０３に送る。次いで、ＲＤＢＭＳ１０３は上記ＳＱＬコ
マンドを解析し、解析結果を最適化し、それをＲＤＢＭ
Ｓ自身が内蔵している情報に対して実行する。次いで、
ＲＤＢＭＳ１０３は結果表をプロセッサ１０２に送り返
す。プロセッサ１０２は当該結果表をＩ／Ｏ装置１０４
を使用しているエンドユーザに表示する。しかしながら
認識すべき点を挙げると、ＲＤＢＭＳ１０３と対話する
方法はこれ以外にも多数ある。たとえば、バッチ・モー
ドで実行しているコンピュータ・プログラムは、ユーザ
の直接的な対話を必要とせずにＲＤＢＭＳ１０３と対話
することができる。
【００１６】認識すべき点を挙げると、ここで使用して
いる用語「プロセッサ」はたとえばＣＰＵ（中央処理装
置）を含む任意の処理装置を含むことを意図している。
ここで使用している用語「メモリ」はプロセッサすなわ
ちＣＰＵに付随するメモリ、たとえばＲＡＭ、ＲＯＭ、
固定記憶装置（たとえばハード・ディスク駆動装置）、
着脱可能記憶装置（たとえばディスケット）などを含む
ことを意図している。さらに、ここで使用している用語
「入出力装置」すなわち「Ｉ／Ｏ装置」は、たとえば照
会を作成するおよび／または処理装置にデータを入力す
る少なくとも１つの入力装置（たとえばキーボード）、
および／または、照会結果および／または処理装置に付
随する他の結果を提示する少なくとも１つの出力装置
（たとえばＣＲＴディスプレイおよび／またはプリン
タ）を含むことを意図している。あるプロセッサに付随
する様々な構成要素は他のプロセッサが共用することが
できる、という点も理解すべきである。以上のとおりで
あるから、ここで説明する本発明の手法を実行する命令
すなわちコードを含むソフトウェア・コンポーネント
は、プロセッサに付随する少なくとも１つの記憶装置
（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置な
ど）に格納しておき、使用しうる状態になったら一部ま
たは全部を（たとえばＲＡＭ）にロードし、ＣＰＵが実
行する。
いる用語「プロセッサ」はたとえばＣＰＵ（中央処理装
置）を含む任意の処理装置を含むことを意図している。
ここで使用している用語「メモリ」はプロセッサすなわ
ちＣＰＵに付随するメモリ、たとえばＲＡＭ、ＲＯＭ、
固定記憶装置（たとえばハード・ディスク駆動装置）、
着脱可能記憶装置（たとえばディスケット）などを含む
ことを意図している。さらに、ここで使用している用語
「入出力装置」すなわち「Ｉ／Ｏ装置」は、たとえば照
会を作成するおよび／または処理装置にデータを入力す
る少なくとも１つの入力装置（たとえばキーボード）、
および／または、照会結果および／または処理装置に付
随する他の結果を提示する少なくとも１つの出力装置
（たとえばＣＲＴディスプレイおよび／またはプリン
タ）を含むことを意図している。あるプロセッサに付随
する様々な構成要素は他のプロセッサが共用することが
できる、という点も理解すべきである。以上のとおりで
あるから、ここで説明する本発明の手法を実行する命令
すなわちコードを含むソフトウェア・コンポーネント
は、プロセッサに付随する少なくとも１つの記憶装置
（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置な
ど）に格納しておき、使用しうる状態になったら一部ま
たは全部を（たとえばＲＡＭ）にロードし、ＣＰＵが実
行する。
【００１７】図１に示す典型的な環境は本発明を限定す
ることを意図していない、ということは当業者が容易に
理解しうる点である。本発明の本旨と範囲の内で他の代
替可能な環境を用いることもできる、ということも当業
者が容易に認識しうる点である。
ることを意図していない、ということは当業者が容易に
理解しうる点である。本発明の本旨と範囲の内で他の代
替可能な環境を用いることもできる、ということも当業
者が容易に認識しうる点である。
【００１８】図２は典型的なＲＤＢＭＳ１０３を示す図
である。ＲＤＢＭＳ１０３は照会コンパイラ２０１、コ
ード・ジェネレータ２０２、実行エンジン２０３、アク
セス・メソッド・エンジン２０４、バッファ・マネージ
ャ２０５、ユーティリティ・エンジン２０６、データ・
マネージャ２０７、および残余コンポーネント２０８を
備えている。
である。ＲＤＢＭＳ１０３は照会コンパイラ２０１、コ
ード・ジェネレータ２０２、実行エンジン２０３、アク
セス・メソッド・エンジン２０４、バッファ・マネージ
ャ２０５、ユーティリティ・エンジン２０６、データ・
マネージャ２０７、および残余コンポーネント２０８を
備えている。
【００１９】本発明の好適な実施形態では、ＲＤＢＭＳ
１０３としては、インターナショナル・ビジネス・マシ
ーンズ・コーポレーションがＵＮＩＸ（Ｒ）、ＷＩＮＤ
ＯＷＳ（Ｒ） ＮＴその他のシステム用に提供している
ＤＢ２製品を用いることができる。しかしながら、認識
すべき点を挙げると、本発明はＤＢ２製品であれ他の製
品であれそれに付随する任意のリレーショナル・データ
ベース・ソフトウェアに適用することができる。
１０３としては、インターナショナル・ビジネス・マシ
ーンズ・コーポレーションがＵＮＩＸ（Ｒ）、ＷＩＮＤ
ＯＷＳ（Ｒ） ＮＴその他のシステム用に提供している
ＤＢ２製品を用いることができる。しかしながら、認識
すべき点を挙げると、本発明はＤＢ２製品であれ他の製
品であれそれに付随する任意のリレーショナル・データ
ベース・ソフトウェアに適用することができる。
【００２０】動作中、ＲＤＢＭＳ１０３はたとえばコン
ピュータ・システムで実行され、ネットワーク・インタ
フェースを用いて少なくとも１つのクライアントと通信
する。ＲＤＢＭＳ１０３はユーザからコマンドを介して
命令を受け取ることにより、スタンドアロン・サーバ・
モードで動作することもできる。通常、クライアント／
ユーザがＲＤＢＭＳ１０３が処理するＳＱＬコマンドを
発行すると、結果が返される。動作中、照会コンパイラ
２０１は入力ＳＱＬコマンドを解析したのち、コード・
ジェネレータ２０２を使って実行計画を作成する。解析
したＳＱＬコマンドは通常、内部表現に変換したのち、
最適化する。最適化には正しい結果を得るために代替可
能なストラテジー（戦略）をいくつか参照するステップ
と、最も効率的なストラテジーを選択するステップとが
含まれる。実行エンジン２０３は実行計画を解釈・実行
して所望の結果を生成する。その際、実行エンジン２０
３はデータ・マネージャ２０７に要求を出して表から情
報を取得する。これは利用可能な索引を使い、表群をス
キャンし、など、照会コンパイラ２１０（または別個の
最適化プログラム）が決めた方法で行なう。実行エンジ
ン２０３はアクセス・メソッド・エンジン２０４を使
い、当該アクセス・メソッド・エンジン２０４（または
外部）に格納されている基礎データベース表群に効率的
にアクセスする。次いで、関連するデータ項目を取得し
てバッファ・マネージャ２０５に格納し当該データの再
利用に備える。通常、リレーショナル・データベース管
理システムは順次表スキャン方式に加え、索引基準表ア
クセス方式を備えている。ＲＤＢＭＳシステムでは、Ｂ
ツリー索引が最も好適な索引手法である。また、ＲＤＢ
ＭＳシステムのなかには、少なくとも１つの列（または
索引）を用いて基礎データをクラスタ化すること、およ
び／または区分することができるものもある。
ピュータ・システムで実行され、ネットワーク・インタ
フェースを用いて少なくとも１つのクライアントと通信
する。ＲＤＢＭＳ１０３はユーザからコマンドを介して
命令を受け取ることにより、スタンドアロン・サーバ・
モードで動作することもできる。通常、クライアント／
ユーザがＲＤＢＭＳ１０３が処理するＳＱＬコマンドを
発行すると、結果が返される。動作中、照会コンパイラ
２０１は入力ＳＱＬコマンドを解析したのち、コード・
ジェネレータ２０２を使って実行計画を作成する。解析
したＳＱＬコマンドは通常、内部表現に変換したのち、
最適化する。最適化には正しい結果を得るために代替可
能なストラテジー（戦略）をいくつか参照するステップ
と、最も効率的なストラテジーを選択するステップとが
含まれる。実行エンジン２０３は実行計画を解釈・実行
して所望の結果を生成する。その際、実行エンジン２０
３はデータ・マネージャ２０７に要求を出して表から情
報を取得する。これは利用可能な索引を使い、表群をス
キャンし、など、照会コンパイラ２１０（または別個の
最適化プログラム）が決めた方法で行なう。実行エンジ
ン２０３はアクセス・メソッド・エンジン２０４を使
い、当該アクセス・メソッド・エンジン２０４（または
外部）に格納されている基礎データベース表群に効率的
にアクセスする。次いで、関連するデータ項目を取得し
てバッファ・マネージャ２０５に格納し当該データの再
利用に備える。通常、リレーショナル・データベース管
理システムは順次表スキャン方式に加え、索引基準表ア
クセス方式を備えている。ＲＤＢＭＳシステムでは、Ｂ
ツリー索引が最も好適な索引手法である。また、ＲＤＢ
ＭＳシステムのなかには、少なくとも１つの列（または
索引）を用いて基礎データをクラスタ化すること、およ
び／または区分することができるものもある。
【００２１】本発明によると、ここで説明する多次元ク
ラスタリング手法は次に示すＲＤＢＭＳ１０３の主要コ
ンポーネントに影響を及ぼす。
ラスタリング手法は次に示すＲＤＢＭＳ１０３の主要コ
ンポーネントに影響を及ぼす。
【００２２】（１）データ・マネージャ２０７とアクセ
ス・メソッド・エンジン２０４：データにアクセスする
ために、Ｂツリー索引手法を変更するのに加え、新たな
データ設計とレコード管理構造をいくつか提供する。ま
た、コンカレント・アクセスとデータ構造の復旧とを管
理する手法を新たにサポートする。
ス・メソッド・エンジン２０４：データにアクセスする
ために、Ｂツリー索引手法を変更するのに加え、新たな
データ設計とレコード管理構造をいくつか提供する。ま
た、コンカレント・アクセスとデータ構造の復旧とを管
理する手法を新たにサポートする。
【００２３】（２）実行エンジン２０３：データ・マネ
ージャ２０７とアクセス・メソッド・エンジン２０４に
生じた変化を利用する、照会処理用の演算子とデータベ
ース保守操作とを新たに提供する。
ージャ２０７とアクセス・メソッド・エンジン２０４に
生じた変化を利用する、照会処理用の演算子とデータベ
ース保守操作とを新たに提供する。
【００２４】（３）照会コンパイラ２０１とコード・ジ
ェネレータ２０２：新たな演算子と既存の演算子との間
で選択を行なうコスト基準の新たな手法を提供する。
ェネレータ２０２：新たな演算子と既存の演算子との間
で選択を行なうコスト基準の新たな手法を提供する。
【００２５】（４）ユーティリティ・エンジン２０６：
ユーティリティ操作を実行する新たな方式、たとえばバ
ルク（大量）ロードやデータ認識などを提供する。
ユーティリティ操作を実行する新たな方式、たとえばバ
ルク（大量）ロードやデータ認識などを提供する。
【００２６】一般に、ＲＤＢＭＳ１０３ソフトウェアお
よびそれに由来する命令群は、コンピュータ読み取り可
能な媒体すなわちコンピュータによって読み取ることの
できる媒体に有形的に記録することができる。ＲＤＢＭ
Ｓ１０３ソフトウェアおよびそれに由来する命令群はす
べて、コンピュータ・システムによって読み取られて実
行されると、本発明を実装および／または使用するのに
必要なステップを当該コンピュータ・システムに実行さ
せる命令群から構成されている。ＲＤＢＭＳ１０３ソフ
トウェアおよびそれに由来する命令群は、オペレーティ
ング・システムの制御の下で、適切なデータ記憶装置か
ら実動中に使用される、コンピュータ・システムのメモ
リにロードする。
よびそれに由来する命令群は、コンピュータ読み取り可
能な媒体すなわちコンピュータによって読み取ることの
できる媒体に有形的に記録することができる。ＲＤＢＭ
Ｓ１０３ソフトウェアおよびそれに由来する命令群はす
べて、コンピュータ・システムによって読み取られて実
行されると、本発明を実装および／または使用するのに
必要なステップを当該コンピュータ・システムに実行さ
せる命令群から構成されている。ＲＤＢＭＳ１０３ソフ
トウェアおよびそれに由来する命令群は、オペレーティ
ング・システムの制御の下で、適切なデータ記憶装置か
ら実動中に使用される、コンピュータ・システムのメモ
リにロードする。
【００２７】図３は２次元にクラスタ化された典型的な
多次元表を示す図である。図３に示す多次元表は「年月
（YearAndMonth）」３００なる次元と「州（Provinc
e）」３１０なる次元にクラスタ化されている。多次元
表中のレコードはブロック群に格納されている。各ブロ
ックはディスクその他好適な媒体に格納された連続ペー
ジから成るある分量のエクステントを保有している。
（エクステントとは記憶媒体上で１つのデータ・セット
が占める領域のことである。）図３では、ブロックは長
円で表されており、多次元表に割り当てられたエクステ
ント群の論理順序に従って番号が付されている。たとえ
ば、長円３０１は多次元表中の１番目のブロックすなわ
ちブロック１を指示している。図３中の格子はこれらの
ブロックの論理区分化を表わしている。各正方形（たと
えば正方形３０２）は論理セルを表わしている。格子中
の行または列は特定の次元に対するスライスを表わして
いる。（スライスとはある事象から切り出された薄片の
ことである。）たとえば、州３１０列中の値「ＯＮ」
（「オンタリオ（Ontario)」の略）を含むレコードはす
べて、格子中の「ＯＮ」列によって画定されたスライス
に含まれるブロック群に存在する。実際、このスライス
中の各ブロックは州フィールドが「ＯＮ」であるレコー
ドしか含んでいない。したがって、格子中のこのスライ
スすなわちこの列に、あるブロックが含まれるのは、州
フィールドが「ＯＮ」であるレコードを当該ブロックが
含んでいる場合だけである。図３に示す典型的な多次元
表では、「ＯＮ」州列に対するスライスにはブロック
９、１６、１８、１９、２２、２４、２５、３０、３
６、３９、４１、４２が含まれている。
多次元表を示す図である。図３に示す多次元表は「年月
（YearAndMonth）」３００なる次元と「州（Provinc
e）」３１０なる次元にクラスタ化されている。多次元
表中のレコードはブロック群に格納されている。各ブロ
ックはディスクその他好適な媒体に格納された連続ペー
ジから成るある分量のエクステントを保有している。
（エクステントとは記憶媒体上で１つのデータ・セット
が占める領域のことである。）図３では、ブロックは長
円で表されており、多次元表に割り当てられたエクステ
ント群の論理順序に従って番号が付されている。たとえ
ば、長円３０１は多次元表中の１番目のブロックすなわ
ちブロック１を指示している。図３中の格子はこれらの
ブロックの論理区分化を表わしている。各正方形（たと
えば正方形３０２）は論理セルを表わしている。格子中
の行または列は特定の次元に対するスライスを表わして
いる。（スライスとはある事象から切り出された薄片の
ことである。）たとえば、州３１０列中の値「ＯＮ」
（「オンタリオ（Ontario)」の略）を含むレコードはす
べて、格子中の「ＯＮ」列によって画定されたスライス
に含まれるブロック群に存在する。実際、このスライス
中の各ブロックは州フィールドが「ＯＮ」であるレコー
ドしか含んでいない。したがって、格子中のこのスライ
スすなわちこの列に、あるブロックが含まれるのは、州
フィールドが「ＯＮ」であるレコードを当該ブロックが
含んでいる場合だけである。図３に示す典型的な多次元
表では、「ＯＮ」州列に対するスライスにはブロック
９、１６、１８、１９、２２、２４、２５、３０、３
６、３９、４１、４２が含まれている。
【００２８】ここに示す典型的な表ではブロック１から
開始する順番でブロック群に番号を付したけれども、他
の多くの方法でブロック群を特定しうるということを認
識すべきである。たとえば、表中の１番目のブロックは
ブロック０と名付けることもできる。また当業者が認識
しうるように、本発明の本旨と範囲の内で、表に関係す
る情報の部分を特定する他の様々な方法を案出すること
ができるとともに、異なる用語法を用いることもでき
る。
開始する順番でブロック群に番号を付したけれども、他
の多くの方法でブロック群を特定しうるということを認
識すべきである。たとえば、表中の１番目のブロックは
ブロック０と名付けることもできる。また当業者が認識
しうるように、本発明の本旨と範囲の内で、表に関係す
る情報の部分を特定する他の様々な方法を案出すること
ができるとともに、異なる用語法を用いることもでき
る。
【００２９】図４は図３の典型的な多次元表の各次元に
次元ブロック索引を備えた図である。あるスライスを構
成しているのはどのブロックであるか、すなわち特定の
次元キー値を有するレコードをすべて含むのはどのブロ
ックであるかを判断するのを容易にするために、表を生
成するときに各次元ごとに次元ブロック索引を自動的に
生成する。したがって、年月次元３００には次元ブロッ
ク索引４００を生成し、州次元３１０には次元ブロック
索引４１０を生成する。各次元ブロック索引は既存のレ
コード基準索引と同じ方法で構築することができる。た
だし、リーフ（葉）のレベルでは、キーはレコードＩＤ
（ＲＩＤ）ではなくブロックＩＤ（ＢＩＤ）を指示して
いる。都合のよいことに、各ブロックはレコード群から
成る多数のページを潜在的に含んでいるから、これらの
ブロック索引はＲＩＤ索引よりもはるかに小さい。ま
た、これらのブロック索引は新たなブロックが必要にな
りそれをセルに付加するとき、またはセルから除去しう
るように既存のブロックを空（から）にするときに更新
するだけでよい。
次元ブロック索引を備えた図である。あるスライスを構
成しているのはどのブロックであるか、すなわち特定の
次元キー値を有するレコードをすべて含むのはどのブロ
ックであるかを判断するのを容易にするために、表を生
成するときに各次元ごとに次元ブロック索引を自動的に
生成する。したがって、年月次元３００には次元ブロッ
ク索引４００を生成し、州次元３１０には次元ブロック
索引４１０を生成する。各次元ブロック索引は既存のレ
コード基準索引と同じ方法で構築することができる。た
だし、リーフ（葉）のレベルでは、キーはレコードＩＤ
（ＲＩＤ）ではなくブロックＩＤ（ＢＩＤ）を指示して
いる。都合のよいことに、各ブロックはレコード群から
成る多数のページを潜在的に含んでいるから、これらの
ブロック索引はＲＩＤ索引よりもはるかに小さい。ま
た、これらのブロック索引は新たなブロックが必要にな
りそれをセルに付加するとき、またはセルから除去しう
るように既存のブロックを空（から）にするときに更新
するだけでよい。
【００３０】スライス（すなわちある次元における特定
のキー値を有するレコードをすべて備えたページ群を含
むブロック群の集合）は、関連する次元ブロック索引中
に当該キー値に対するＢＩＤリストによって表わすこと
ができる。
のキー値を有するレコードをすべて備えたページ群を含
むブロック群の集合）は、関連する次元ブロック索引中
に当該キー値に対するＢＩＤリストによって表わすこと
ができる。
【００３１】図４に示す典型的な多次元表において、州
次元が「ＯＮ」であるレコードをすべて含むスライスを
探すには、州次元ブロック索引でこのキー値を調べる。
すると、次に示すキーが見つかる。 ＜ＯＮ：９、１６、１８、１９、２２、２４、２５、３
０、３６、３９、４１、４２＞ ただし、キーは＜キー値：ＢＩＤ＞対という形をしてい
る。
次元が「ＯＮ」であるレコードをすべて含むスライスを
探すには、州次元ブロック索引でこのキー値を調べる。
すると、次に示すキーが見つかる。 ＜ＯＮ：９、１６、１８、１９、２２、２４、２５、３
０、３６、３９、４１、４２＞ ただし、キーは＜キー値：ＢＩＤ＞対という形をしてい
る。
【００３２】上記キーはキー値（すなわち「ＯＮ」）と
ＢＩＤのリストから構成されている。各ＢＩＤはブロッ
クの場所を含んでいる。この例では、列挙されているブ
ロック番号は多次元表の格子中にある「ＯＮ」列（すな
わちスライス）中にあるものと同じであることが分か
る。同様に、年月次元が「９９０２」であるレコードを
すべて含むブロックのリストを探すには、年月次元索引
でこのキー値を調べると、次に示すキーが見つかる。 ＜９９０２：２、５、７、８、１４、１５、１７、１
８、３１、３２、３３、４３＞
ＢＩＤのリストから構成されている。各ＢＩＤはブロッ
クの場所を含んでいる。この例では、列挙されているブ
ロック番号は多次元表の格子中にある「ＯＮ」列（すな
わちスライス）中にあるものと同じであることが分か
る。同様に、年月次元が「９９０２」であるレコードを
すべて含むブロックのリストを探すには、年月次元索引
でこのキー値を調べると、次に示すキーが見つかる。 ＜９９０２：２、５、７、８、１４、１５、１７、１
８、３１、３２、３３、４３＞
【００３３】多次元表のクラスタリングはＳＱＬ言語で
特定することができる。それには、Ｃｒｅａｔｅ Ｔａ
ｂｌｅ（表作成）ステートメントまたはＡｌｔｅｒ Ｔ
ａｂｌｅ（表変更）ステートメントに付加する文節に、
クラスタリング属性を特定しうる適切なものを使用す
る。たとえば、次に示すＣｒｅａｔｅ Ｔａｂｌｅステ
ートメントを用いてこの例の表を作成することができ
る。 CREATE TABLE TABLE＿1 (Date DATE, Province CHAR
(2), YearAndMonth INTEGER DIMENSIONS (YearAndMonth, Province);
特定することができる。それには、Ｃｒｅａｔｅ Ｔａ
ｂｌｅ（表作成）ステートメントまたはＡｌｔｅｒ Ｔ
ａｂｌｅ（表変更）ステートメントに付加する文節に、
クラスタリング属性を特定しうる適切なものを使用す
る。たとえば、次に示すＣｒｅａｔｅ Ｔａｂｌｅステ
ートメントを用いてこの例の表を作成することができ
る。 CREATE TABLE TABLE＿1 (Date DATE, Province CHAR
(2), YearAndMonth INTEGER DIMENSIONS (YearAndMonth, Province);
【００３４】この場合、年月（YearAndMonth）次元と州
（Province）次元はTABLE ＿1 用にDIMENSIONS文節を用
いて定義されている。多次元表のクラスタリングは当該
多次元表中のすべてのデータに適用されなければならな
い。特に、既存の表にＡｌｔｅｒ Ｔａｂｌｅコマンド
を用いてクラスタリングを特定する場合には、データの
再編成も実行する必要がある。留意点を挙げると、クラ
スタリング属性用のブロック索引は自動的に作成するこ
とができる。
（Province）次元はTABLE ＿1 用にDIMENSIONS文節を用
いて定義されている。多次元表のクラスタリングは当該
多次元表中のすべてのデータに適用されなければならな
い。特に、既存の表にＡｌｔｅｒ Ｔａｂｌｅコマンド
を用いてクラスタリングを特定する場合には、データの
再編成も実行する必要がある。留意点を挙げると、クラ
スタリング属性用のブロック索引は自動的に作成するこ
とができる。
【００３５】図５は典型的な複合次元索引用のデータ構
造を示す図である。レコードを表に挿入するとき、その
次元値用のセルが既に存在するかどうか知る必要があ
る。上記セルが存在する場合、可能なら当該レコードを
上記セルの既存のブロックに挿入し、既存のブロックが
満杯なら上記セルに別のブロックを付加する。上記セル
が存在しない場合には、新たなセルを作成しそれにブロ
ックを付加する必要がある。これを自動的な保守操作と
するには、複合次元索引と呼ばれ多次元表を作成すると
きに作成しうるブロック索引を新たに用いて実装するこ
とができる。この複合次元索引は多次元表中のすべての
次元列について作成するから、各キー値は表中の特定の
セルに対応し、そのＢＩＤリストは当該セルを構成する
ブロックから成る。これを図５に示す。この複合ブロッ
ク索引によって、次元用の値の特定の集合を有するブロ
ックを迅速かつ効率的に検索するのが容易になる。複合
ブロック索引は挿入操作中に、対象とする多次元表の次
元群によるデータの物理的クラスタリングを動的に管理
・保守するのにも使うことができる。認識すべき点を挙
げると、Ｒツリーなどの多次元索引構造も、それらがレ
コードまたはオブジェクトではなくブロックを指示して
いる場合には、複合次元索引を実装するのに使用するこ
とができる。
造を示す図である。レコードを表に挿入するとき、その
次元値用のセルが既に存在するかどうか知る必要があ
る。上記セルが存在する場合、可能なら当該レコードを
上記セルの既存のブロックに挿入し、既存のブロックが
満杯なら上記セルに別のブロックを付加する。上記セル
が存在しない場合には、新たなセルを作成しそれにブロ
ックを付加する必要がある。これを自動的な保守操作と
するには、複合次元索引と呼ばれ多次元表を作成すると
きに作成しうるブロック索引を新たに用いて実装するこ
とができる。この複合次元索引は多次元表中のすべての
次元列について作成するから、各キー値は表中の特定の
セルに対応し、そのＢＩＤリストは当該セルを構成する
ブロックから成る。これを図５に示す。この複合ブロッ
ク索引によって、次元用の値の特定の集合を有するブロ
ックを迅速かつ効率的に検索するのが容易になる。複合
ブロック索引は挿入操作中に、対象とする多次元表の次
元群によるデータの物理的クラスタリングを動的に管理
・保守するのにも使うことができる。認識すべき点を挙
げると、Ｒツリーなどの多次元索引構造も、それらがレ
コードまたはオブジェクトではなくブロックを指示して
いる場合には、複合次元索引を実装するのに使用するこ
とができる。
【００３６】図６は図４の多次元表に新たな次元を備え
て拡張したものを示す図である。いま、図６に示すよう
に、年月次元３００、州次元３１０、および色（Color)
次元６００から成る次元を備えた多次元表を考える。こ
の多次元表は論理立方体と考えることができる。この例
では、４つのブロック索引を作成することになる。すな
わち、個々の次元（すなわち年月次元３００、州次元３
１０、および色次元６００）ごとに１つずつのブロック
索引と、キーとしてこれらの次元のすべてを備えた複合
次元索引（図示せず）とである。
て拡張したものを示す図である。いま、図６に示すよう
に、年月次元３００、州次元３１０、および色（Color)
次元６００から成る次元を備えた多次元表を考える。こ
の多次元表は論理立方体と考えることができる。この例
では、４つのブロック索引を作成することになる。すな
わち、個々の次元（すなわち年月次元３００、州次元３
１０、および色次元６００）ごとに１つずつのブロック
索引と、キーとしてこれらの次元のすべてを備えた複合
次元索引（図示せず）とである。
【００３７】本発明の目標の１つは効率的な照会処理を
容易にすることである。以下、本発明によって容易にな
る照会処理方法を説明する。年月次元３００、州次元３
１０、および色次元６００から成る次元を備えた、図６
に示す３次元立方体を考える。たとえば「すべての日付
と地域にわたって「色が『赤』である」合計売上高はい
くらか」のような照会は、いくつかの異なる方法で処理
することができる。この照会を処理する方法には、次に
示す選択肢がある。 （１）表スキャン：表全体をスキャンして「色が『赤』
である」行だけを選択する。 （２）ブロック・スキャン：色に関するブロック索引を
使って検索範囲をブロックの特定の集合に狭める。 （３）レコード・スキャン：（存在する場合には）色に
関するレコード基準索引を使って検索範囲をレコードの
特定の集合に狭める。
容易にすることである。以下、本発明によって容易にな
る照会処理方法を説明する。年月次元３００、州次元３
１０、および色次元６００から成る次元を備えた、図６
に示す３次元立方体を考える。たとえば「すべての日付
と地域にわたって「色が『赤』である」合計売上高はい
くらか」のような照会は、いくつかの異なる方法で処理
することができる。この照会を処理する方法には、次に
示す選択肢がある。 （１）表スキャン：表全体をスキャンして「色が『赤』
である」行だけを選択する。 （２）ブロック・スキャン：色に関するブロック索引を
使って検索範囲をブロックの特定の集合に狭める。 （３）レコード・スキャン：（存在する場合には）色に
関するレコード基準索引を使って検索範囲をレコードの
特定の集合に狭める。
【００３８】照会最適化プログラムでコスト・モデルを
用いることにより、これらの選択肢のうちから最良のも
のを見つけ出すことができる。ブロック・スキャン方法
は本発明で導入された新しい操作である。このブロック
・スキャンは次に示す２つのステップで実行する。 (i) ブロック索引をスキャンして照会述語を満たすブロ
ックＩＤを見つけ出す。 (ii)当該ブロック中のレコードをすべて処理する。 これは余分な述語を含んでいてもよい。ブロック・スキ
ャン操作が最も効率的なのは、所定の照会に対して１つ
のブロック、ブロックの集合、またはレコードの集合の
大部分を処理する必要がある場合である。このような要
件はデータウェアハウスではきわめて普通のことであ
る。たとえば、上述した照会はブロックの全体集合への
アクセスを含むものと考えられる。したがって、この照
会を処理する方法としては、ブロック・スキャン操作が
最も効率的な方法になると考えられる。
用いることにより、これらの選択肢のうちから最良のも
のを見つけ出すことができる。ブロック・スキャン方法
は本発明で導入された新しい操作である。このブロック
・スキャンは次に示す２つのステップで実行する。 (i) ブロック索引をスキャンして照会述語を満たすブロ
ックＩＤを見つけ出す。 (ii)当該ブロック中のレコードをすべて処理する。 これは余分な述語を含んでいてもよい。ブロック・スキ
ャン操作が最も効率的なのは、所定の照会に対して１つ
のブロック、ブロックの集合、またはレコードの集合の
大部分を処理する必要がある場合である。このような要
件はデータウェアハウスではきわめて普通のことであ
る。たとえば、上述した照会はブロックの全体集合への
アクセスを含むものと考えられる。したがって、この照
会を処理する方法としては、ブロック・スキャン操作が
最も効率的な方法になると考えられる。
【００３９】留意点を挙げると、多次元表に対してＲＩ
Ｄ索引もサポートすれば、索引ＡＮＤ手法および索引Ｏ
Ｒ手法によってＲＩＤ索引とブロック索引とを組み合わ
せることができる。あるいは、多次元表を既存の任意の
表と同様に処理することもできる。たとえば、多次元表
に対してトリガー、参照保全性、ビュー、および自動サ
マリー表を定義することができる。
Ｄ索引もサポートすれば、索引ＡＮＤ手法および索引Ｏ
Ｒ手法によってＲＩＤ索引とブロック索引とを組み合わ
せることができる。あるいは、多次元表を既存の任意の
表と同様に処理することもできる。たとえば、多次元表
に対してトリガー、参照保全性、ビュー、および自動サ
マリー表を定義することができる。
【００４０】図７（ａ）（ｂ）（ｃ）はブロック索引を
用いて索引ＡＮＤを実行する方法を示す図である。い
ま、図６に示す３次元立方体に対する「色が『青』であ
り、かつ（ＡＮＤ）、州が『ＱＢ』である」という照会
を考える。まず、「色が『青』である」ブロックをすべ
て含むスライスを求める。それには、多次元表に付随す
る色次元ブロック索引で「青」キー値を探す。その結
果、次に示すキーが見つかる。 ＜青：１、２、３、４、５、６、７、８、９、１０、１
１、１２、１３、１４＞ これは図７（ａ）の立体図に示す（灰色で強調表示し
た）スライス７１５に対応している。
用いて索引ＡＮＤを実行する方法を示す図である。い
ま、図６に示す３次元立方体に対する「色が『青』であ
り、かつ（ＡＮＤ）、州が『ＱＢ』である」という照会
を考える。まず、「色が『青』である」ブロックをすべ
て含むスライスを求める。それには、多次元表に付随す
る色次元ブロック索引で「青」キー値を探す。その結
果、次に示すキーが見つかる。 ＜青：１、２、３、４、５、６、７、８、９、１０、１
１、１２、１３、１４＞ これは図７（ａ）の立体図に示す（灰色で強調表示し
た）スライス７１５に対応している。
【００４１】次いで、「州が『ＱＢ』である」レコード
をすべて含むブロックを求める。それには、州次元ブロ
ック索引で「ＱＢ」キー値を探す。その結果、次に示す
キーが見つかる。 ＜ＱＢ：１１、１２、１３、１４、２７、２８、３５、
３７、４０、５１＞ これは図７（ｂ）の立体図に示すスライス７２５に対応
している。上記２つのキー値を有するレコードをすべて
含むブロックの集合を探すには、上記２つのスライスの
交差部を見つける必要がある。これを行なうには、上記
２つのＢＩＤリストの索引ＡＮＤをとる。この例では、
共通ＢＩＤ値は「１１、１２、１３、１４」である。こ
れは図７（ｃ）に示す立体図の区画７３５に対応してい
る。
をすべて含むブロックを求める。それには、州次元ブロ
ック索引で「ＱＢ」キー値を探す。その結果、次に示す
キーが見つかる。 ＜ＱＢ：１１、１２、１３、１４、２７、２８、３５、
３７、４０、５１＞ これは図７（ｂ）の立体図に示すスライス７２５に対応
している。上記２つのキー値を有するレコードをすべて
含むブロックの集合を探すには、上記２つのスライスの
交差部を見つける必要がある。これを行なうには、上記
２つのＢＩＤリストの索引ＡＮＤをとる。この例では、
共通ＢＩＤ値は「１１、１２、１３、１４」である。こ
れは図７（ｃ）に示す立体図の区画７３５に対応してい
る。
【００４２】スキャンすべきブロックのリストが得られ
たら、各ブロックに対してミニ・リレーショナル・スキ
ャンを実行するだけでよい。この操作には入出力（Ｉ／
Ｏ）が１回しかない（したがって高速に行なうことがで
きる）。なぜなら、１つのブロックはディスクに１つの
エクステントとして格納され、１つの単位としてバッフ
ァプールに読み取ることができるからである。また、照
会述語を再適用する必要があり、かつ、一部の述語が次
元値にしか存在しない場合には、それらの述語をブロッ
ク中の１つのレコードに再適用するだけでよい。なぜな
ら、ブロック中のすべてのレコードに同じ次元キー値が
存在することが保証されているからである。また、他に
述語があっても、それらがブロック中の残りのレコード
に存在するかどうか検査するだけでよい。
たら、各ブロックに対してミニ・リレーショナル・スキ
ャンを実行するだけでよい。この操作には入出力（Ｉ／
Ｏ）が１回しかない（したがって高速に行なうことがで
きる）。なぜなら、１つのブロックはディスクに１つの
エクステントとして格納され、１つの単位としてバッフ
ァプールに読み取ることができるからである。また、照
会述語を再適用する必要があり、かつ、一部の述語が次
元値にしか存在しない場合には、それらの述語をブロッ
ク中の１つのレコードに再適用するだけでよい。なぜな
ら、ブロック中のすべてのレコードに同じ次元キー値が
存在することが保証されているからである。また、他に
述語があっても、それらがブロック中の残りのレコード
に存在するかどうか検査するだけでよい。
【００４３】ブロック基準索引ＡＮＤ方式はビット・マ
ップ方式を用いることができるから、きわめて効率的で
ある。また、ブロック・レベル索引はＲＩＤ索引よりも
小さいから、索引ＡＮＤに要する処理時間はきわめて少
ない。最後に、ブロックの交差リストはブロック基準Ｉ
／Ｏ操作を使って効率的にアクセスすることができる。
全体として、ここで説明した操作はきわめて効率的であ
り、この手法以前の既存のものよりもはるかに高速であ
る。
ップ方式を用いることができるから、きわめて効率的で
ある。また、ブロック・レベル索引はＲＩＤ索引よりも
小さいから、索引ＡＮＤに要する処理時間はきわめて少
ない。最後に、ブロックの交差リストはブロック基準Ｉ
／Ｏ操作を使って効率的にアクセスすることができる。
全体として、ここで説明した操作はきわめて効率的であ
り、この手法以前の既存のものよりもはるかに高速であ
る。
【００４４】多次元表用に既存のＲＩＤ基準索引もサポ
ートすれば、索引ＡＮＤ操作と索引ＯＲ操作によってＲ
ＩＤ索引とブロック索引とを組み合わせることができ
る。
ートすれば、索引ＡＮＤ操作と索引ＯＲ操作によってＲ
ＩＤ索引とブロック索引とを組み合わせることができ
る。
【００４５】上述したように、ブロック索引を用いてブ
ロック基準索引ＯＲ操作も実行することができる。たと
えば、照会が「州が『ＯＮ』であるか、または（Ｏ
Ｒ）、州が『ＢＣ』である」という条件を含んでいる場
合、州ブロック索引をカテゴリごとにスキャンしたの
ち、ＯＲ操作を実行するとブロックの合計リストが得ら
れる。また、このＯＲ操作によれば、たとえば「州が
『ＡＢ』であるか、または（ＯＲ）、色が『赤』であ
る」といった条件の場合に生じる可能性のあるＢＩＤの
重複を除去することができる。
ロック基準索引ＯＲ操作も実行することができる。たと
えば、照会が「州が『ＯＮ』であるか、または（Ｏ
Ｒ）、州が『ＢＣ』である」という条件を含んでいる場
合、州ブロック索引をカテゴリごとにスキャンしたの
ち、ＯＲ操作を実行するとブロックの合計リストが得ら
れる。また、このＯＲ操作によれば、たとえば「州が
『ＡＢ』であるか、または（ＯＲ）、色が『赤』であ
る」といった条件の場合に生じる可能性のあるＢＩＤの
重複を除去することができる。
【００４６】副ブロック索引スキャンもサポートするこ
とができる。副ブロック索引があると、単一のＢＩＤが
多数のキーの下に存在しうることになる。このことはＲ
ＩＤ索引では決してありえない、ということに留意する
必要がある。副ブロック索引を用いてファクト表にアク
セスする際に重要なのは、適格ブロックのスキャンが１
回しかないという点である。すなわち、その１回のスキ
ャンで適格ブロックのすべてのレコードにアクセスする
必要があり、当該ブロックを再度フェッチしてはならな
い。この結果、重複を除去しうるようにブロックの適格
リストを保守することが必要になる。
とができる。副ブロック索引があると、単一のＢＩＤが
多数のキーの下に存在しうることになる。このことはＲ
ＩＤ索引では決してありえない、ということに留意する
必要がある。副ブロック索引を用いてファクト表にアク
セスする際に重要なのは、適格ブロックのスキャンが１
回しかないという点である。すなわち、その１回のスキ
ャンで適格ブロックのすべてのレコードにアクセスする
必要があり、当該ブロックを再度フェッチしてはならな
い。この結果、重複を除去しうるようにブロックの適格
リストを保守することが必要になる。
【００４７】図８は多次元表に付随する典型的なブロッ
ク・マップを示す図である。ブロック・マップには、特
定の多次元表に属す各ブロックの現在の状態が記録され
ている。たとえば、このブロック・マップ中の要素８０
１は多次元表のブロック０を表わしている。その使用可
能状態は「Ｘ」であり、予約済みであることを表わして
いる。したがって、ブロック０は多次元表のデータ行を
格納するのにまったく使用できない。ブロック・マップ
中の要素８０２はブロック８を表わしている。その使用
可能状態は「Ｕ」であり、使用中であることを表わして
いる。同様に、ブロック１〜７、１０〜１５、１７、２
０、２５、２６も使用中である。このことは多次元表中
のレコードはこれらのブロック中に存在するということ
を意味している。ブロック・マップ中の要素８０３はブ
ロック１９を表わしている。その使用可能状態は「Ｆ」
であり、空（から）であることを表わしている。同様
に、ブロック２１、２３、２４、２７〜２９も空であ
る。このことはこれらのブロックが現在、多次元表によ
って使用されておらず、使用可能であることを意味して
いる。ブロック・マップ中の要素８０４はブロック２２
を表している。その使用可能状態は「Ｌ」であり、当該
ブロックは最近に情報がロードされたことを表わしてい
る。同様に、ブロック９、１６、３０〜３３も最近にロ
ードされたブロックである。ブロック・マップ中の要素
８０６はブロック１８を表わしている。その使用可能状
態は「Ｃ」である。ブロック１８は以前にロードされた
ものであるが、依然として制約検査を行なう必要があ
る。
ク・マップを示す図である。ブロック・マップには、特
定の多次元表に属す各ブロックの現在の状態が記録され
ている。たとえば、このブロック・マップ中の要素８０
１は多次元表のブロック０を表わしている。その使用可
能状態は「Ｘ」であり、予約済みであることを表わして
いる。したがって、ブロック０は多次元表のデータ行を
格納するのにまったく使用できない。ブロック・マップ
中の要素８０２はブロック８を表わしている。その使用
可能状態は「Ｕ」であり、使用中であることを表わして
いる。同様に、ブロック１〜７、１０〜１５、１７、２
０、２５、２６も使用中である。このことは多次元表中
のレコードはこれらのブロック中に存在するということ
を意味している。ブロック・マップ中の要素８０３はブ
ロック１９を表わしている。その使用可能状態は「Ｆ」
であり、空（から）であることを表わしている。同様
に、ブロック２１、２３、２４、２７〜２９も空であ
る。このことはこれらのブロックが現在、多次元表によ
って使用されておらず、使用可能であることを意味して
いる。ブロック・マップ中の要素８０４はブロック２２
を表している。その使用可能状態は「Ｌ」であり、当該
ブロックは最近に情報がロードされたことを表わしてい
る。同様に、ブロック９、１６、３０〜３３も最近にロ
ードされたブロックである。ブロック・マップ中の要素
８０６はブロック１８を表わしている。その使用可能状
態は「Ｃ」である。ブロック１８は以前にロードされた
ものであるが、依然として制約検査を行なう必要があ
る。
【００４８】認識すべき点を挙げると、図８に示すブロ
ック・マップは特定の値を有する様々な状態フラグを備
えているけれども、他の値を用いて異なるブロック状態
または新たなブロック状態を反映させることもできる。
さらに認識すべき点を挙げると、新たなブロックその他
の情報を表わす新たな要素を動的に割り当てうるような
方法で、ビット・マップのデータ構造を構築することも
できる。
ック・マップは特定の値を有する様々な状態フラグを備
えているけれども、他の値を用いて異なるブロック状態
または新たなブロック状態を反映させることもできる。
さらに認識すべき点を挙げると、新たなブロックその他
の情報を表わす新たな要素を動的に割り当てうるような
方法で、ビット・マップのデータ構造を構築することも
できる。
【００４９】各ブロックは当該ブロックの第１ページの
第１スロットに配置されたヘッダを備えている。ヘッダ
には（他の様々な事項とともに）ブロック状態のコピー
とビット・マップとが格納されている。ブロック状態の
コピーが格納されている結果、ブロック・マップが削除
されたり破損されたりした場合、必要なら当該ブロック
・マップを再作成することができる。上記ビット・マッ
プはブロックの全ページをカバーし空のページを指示す
るものである（たとえば０＝空、１＝非空、オーバーフ
ロー・レコードまたはポインタ・レコードしか備えてい
ない場合であってもこのようにする）。また、各ブロッ
クはそれに付随するフリー・スペース・コントロール・
レコード（ＦＳＣＲ）を備えている。ＦＳＣＲにはペー
ジ・オフセットとページ当たりのフリー・スペースの近
似値とが格納されている。これらのＦＳＣＲはたとえ
ば、ブロックの第１ページに位置し、当該ページの第２
レコードとして格納される。
第１スロットに配置されたヘッダを備えている。ヘッダ
には（他の様々な事項とともに）ブロック状態のコピー
とビット・マップとが格納されている。ブロック状態の
コピーが格納されている結果、ブロック・マップが削除
されたり破損されたりした場合、必要なら当該ブロック
・マップを再作成することができる。上記ビット・マッ
プはブロックの全ページをカバーし空のページを指示す
るものである（たとえば０＝空、１＝非空、オーバーフ
ロー・レコードまたはポインタ・レコードしか備えてい
ない場合であってもこのようにする）。また、各ブロッ
クはそれに付随するフリー・スペース・コントロール・
レコード（ＦＳＣＲ）を備えている。ＦＳＣＲにはペー
ジ・オフセットとページ当たりのフリー・スペースの近
似値とが格納されている。これらのＦＳＣＲはたとえ
ば、ブロックの第１ページに位置し、当該ページの第２
レコードとして格納される。
【００５０】上述した表編成はきわめてスペース効率が
良い。重要なのは、各セルが少なくとも１ブロック分の
データを有するように多次元キーおよび対応するブロッ
ク・サイズを選ぶことである。というのは、最終ブロッ
クのみが部分的に満杯になることが多いからである。こ
の高効率状態は挿入操作、削除操作、またはバックグラ
ウンドでの再編成が頻繁に行なわれる場合であっても維
持することができる。これに対して、ＯＬＡＰ編成では
上述したように、大量の未使用スペースが生じる。
良い。重要なのは、各セルが少なくとも１ブロック分の
データを有するように多次元キーおよび対応するブロッ
ク・サイズを選ぶことである。というのは、最終ブロッ
クのみが部分的に満杯になることが多いからである。こ
の高効率状態は挿入操作、削除操作、またはバックグラ
ウンドでの再編成が頻繁に行なわれる場合であっても維
持することができる。これに対して、ＯＬＡＰ編成では
上述したように、大量の未使用スペースが生じる。
【００５１】図９は本発明の手法に従って実行しうる様
々な保守機能を示す図である。図９には保守機能９００
がある。保守機能９００には、ロード機能９０１、再編
成機能９０２、挿入機能９０３、削除機能９０４、パー
ジ機能９０５、および更新機能９０６がある。以下、こ
れらの機能を詳細に説明する。
々な保守機能を示す図である。図９には保守機能９００
がある。保守機能９００には、ロード機能９０１、再編
成機能９０２、挿入機能９０３、削除機能９０４、パー
ジ機能９０５、および更新機能９０６がある。以下、こ
れらの機能を詳細に説明する。
【００５２】〔ロード機能９０１〕通常、比較的大量の
データを表中にロードするには、挿入コマンドを多数個
発行する代わりにロード機能を使用する。ロード・ユー
ティリティを用いれば、特定の方式でフォーマットした
データ・セットにアクセスし、当該データ・セット中の
情報を使って特定の表に行を作成することができる。
データを表中にロードするには、挿入コマンドを多数個
発行する代わりにロード機能を使用する。ロード・ユー
ティリティを用いれば、特定の方式でフォーマットした
データ・セットにアクセスし、当該データ・セット中の
情報を使って特定の表に行を作成することができる。
【００５３】重要な点を挙げると、ロード・ユーティリ
ティは効率的な方式を用いてデータを表中に挿入する。
多次元表中にデータを首尾よくロードするには、入力を
次元値とともに編成することである。（このことは多次
元表では初期設定として確立されている。）このことが
必要なのは、レコードが次元値とブロック境界によって
適切にクラスタ化されていることを保証するためであ
る。たとえば、＜年月＝９９０３、州＝「ＯＮ」、色＝
「赤」＞に対応する論理セルに対して１つのビン（大
箱）を作成することができる。そうすると、次元属性に
関し同じ値を有するレコードはすべてこのビンに割り当
てることができる。物理的には、各ビンはデータ・ペー
ジ群から成る１つのブロックによって表わすことができ
る。最近に処理されたビンはメモリ中に保持しておき、
それらが満杯になったとき、または他のビンをメモリに
持ってくる必要が生じたときにディスクに書き出す。
ティは効率的な方式を用いてデータを表中に挿入する。
多次元表中にデータを首尾よくロードするには、入力を
次元値とともに編成することである。（このことは多次
元表では初期設定として確立されている。）このことが
必要なのは、レコードが次元値とブロック境界によって
適切にクラスタ化されていることを保証するためであ
る。たとえば、＜年月＝９９０３、州＝「ＯＮ」、色＝
「赤」＞に対応する論理セルに対して１つのビン（大
箱）を作成することができる。そうすると、次元属性に
関し同じ値を有するレコードはすべてこのビンに割り当
てることができる。物理的には、各ビンはデータ・ペー
ジ群から成る１つのブロックによって表わすことができ
る。最近に処理されたビンはメモリ中に保持しておき、
それらが満杯になったとき、または他のビンをメモリに
持ってくる必要が生じたときにディスクに書き出す。
【００５４】処理を減らす方法の１つは、ユーザがＬＯ
ＡＤコマンド中で文節を指定できるようにすることであ
る。ユーザ指定の文節として、たとえば ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ（取り込
み順に変更）文節 を挙げることができる。この任意実行文節（または同じ
効果を有する同様の文節）は、入力データ・セットは既
に格納順であるから処理をより効率的に行なえるという
ことをロード・ユーティリティに知らせるのに使うこと
ができる。これが役に立つ場合がいくつかある。たとえ
ばデータが次元とキー値によって格納済みの場合であ
る。この場合、ロード・ユーティリティは順番を検証す
るだけでよい。別の例として、特定のセル用のレコード
群をロードする場合に有益である。なぜなら、特定のセ
ルに付加するレコード群の次元値はすべて同じだからで
ある。これが当てはまる例として、表が単一の次元から
成り、当該次元の特定値を有するレコード群（たとえば
２００１年２月以降の全レコード）にユーザが大童（お
おわらわ）になっている場合が挙げられる。このような
場合、ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ文
節（またはこれと同じ効果を有する同様の文節）を指定
すると、ロード・ユーティリティはデータが適切に順序
付けられていることを検証するだけでよい。順番が前後
したレコードを発見した場合には、ロード・ユーティリ
ティは処理を停止し、たとえば当該表をロード保留状態
に置いておけばよい。
ＡＤコマンド中で文節を指定できるようにすることであ
る。ユーザ指定の文節として、たとえば ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ（取り込
み順に変更）文節 を挙げることができる。この任意実行文節（または同じ
効果を有する同様の文節）は、入力データ・セットは既
に格納順であるから処理をより効率的に行なえるという
ことをロード・ユーティリティに知らせるのに使うこと
ができる。これが役に立つ場合がいくつかある。たとえ
ばデータが次元とキー値によって格納済みの場合であ
る。この場合、ロード・ユーティリティは順番を検証す
るだけでよい。別の例として、特定のセル用のレコード
群をロードする場合に有益である。なぜなら、特定のセ
ルに付加するレコード群の次元値はすべて同じだからで
ある。これが当てはまる例として、表が単一の次元から
成り、当該次元の特定値を有するレコード群（たとえば
２００１年２月以降の全レコード）にユーザが大童（お
おわらわ）になっている場合が挙げられる。このような
場合、ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ文
節（またはこれと同じ効果を有する同様の文節）を指定
すると、ロード・ユーティリティはデータが適切に順序
付けられていることを検証するだけでよい。順番が前後
したレコードを発見した場合には、ロード・ユーティリ
ティは処理を停止し、たとえば当該表をロード保留状態
に置いておけばよい。
【００５５】〔再編成機能９０２〕再編成ユーティリテ
ィはデータベースにおけるデータの物理的な配置を再編
成するのに使用する。データベースの再編成が必要にな
るのは、フラグメント（断片）化したデータ・スペース
をデフラグするため、またはクラスタ索引を有するレコ
ード群を再構成（クラスタ化）するためである。
ィはデータベースにおけるデータの物理的な配置を再編
成するのに使用する。データベースの再編成が必要にな
るのは、フラグメント（断片）化したデータ・スペース
をデフラグするため、またはクラスタ索引を有するレコ
ード群を再構成（クラスタ化）するためである。
【００５６】多次元表の再編成はクラスタリング索引を
有する表の場合よりもずっと単純であり、必要になる頻
度もずっと低い。多次元表ではクラスタリングを自動的
かつ連続的に継続することができるから、データを再ク
ラスタ化するのにもはや再編成を必要としない。しか
し、多次元表中のスペースを再利用する（具体的にはセ
ル内のスペースを再利用する）、あるいはオーバーフロ
ーしたレコードを除去するのに、再編成ユーティリティ
を使うことができる。多次元表用の再編成ユーティリテ
ィはブロック指向である。複合次元ブロック索引を使う
ことにより、特定ブロック群中のレコード群にアクセス
することができる。それらのレコード群は再編成パラメ
ータ（たとえば必要な空きスペースの量）を用いてを新
たなブロック１つに再構成することができる。この結
果、初期論理セルが多数のブロックを含んでいても、再
構成後のセルはより少ない数のブロックしか含んでいな
い、ということが起こりうる。たとえば、あるセルが初
めにブロック１、１０、３０、４５を含んでいたとす
る。この場合、再編成後に当該セルが新たなブロック
１、２しか含んでいない、ということがありうる。残り
のスペースは他のセルが使用しうるように解放された、
あるいはこの表から完全に除去された。また、再編成の
終わりには新たなブロック・マップの再構築も行なう。
有する表の場合よりもずっと単純であり、必要になる頻
度もずっと低い。多次元表ではクラスタリングを自動的
かつ連続的に継続することができるから、データを再ク
ラスタ化するのにもはや再編成を必要としない。しか
し、多次元表中のスペースを再利用する（具体的にはセ
ル内のスペースを再利用する）、あるいはオーバーフロ
ーしたレコードを除去するのに、再編成ユーティリティ
を使うことができる。多次元表用の再編成ユーティリテ
ィはブロック指向である。複合次元ブロック索引を使う
ことにより、特定ブロック群中のレコード群にアクセス
することができる。それらのレコード群は再編成パラメ
ータ（たとえば必要な空きスペースの量）を用いてを新
たなブロック１つに再構成することができる。この結
果、初期論理セルが多数のブロックを含んでいても、再
構成後のセルはより少ない数のブロックしか含んでいな
い、ということが起こりうる。たとえば、あるセルが初
めにブロック１、１０、３０、４５を含んでいたとす
る。この場合、再編成後に当該セルが新たなブロック
１、２しか含んでいない、ということがありうる。残り
のスペースは他のセルが使用しうるように解放された、
あるいはこの表から完全に除去された。また、再編成の
終わりには新たなブロック・マップの再構築も行なう。
【００５７】〔挿入機能９０３〕挿入には表に新たなレ
コードを作成することが含まれる。挿入操作中、クラス
タリングを維持する必要がある。いま、次元値＜９９０
３，‘ＡＢ’＞を有するレコードを（図４に示すよう
な）多次元表中に挿入することを考える。まず、複合ブ
ロック索引を使ってこの新たなレコード用に適切なブロ
ックを特定する必要がある。それには、（図５に示すよ
うな）複合ブロック索引でキー値「９９０３，ＡＢ」を
探す。その結果、次に示すキーが見つかる。 ＜９９０３，ＡＢ：３，１０＞ この場合、キー値「９９０３，ＡＢ」を有するブロック
はブロック３とブロック１０の２つあることが分かる。
これらのブロックは指定した次元を有するレコードをす
べて含んでいるが、それら以外のレコードは含んでいな
い。したがって、これらのブロックのページのいずれか
にスペースがある場合、これらのブロックのうちの１つ
に新たなレコードを挿入する。これらのブロックのペー
ジのいずれにもスペースがない場合には、多次元表に新
たなブロックを割り当てるか、多次元表中の以前に空に
したブロックを使用する。その際、（図８に示すよう
な）ブロック・マップを探索して空のブロックを見つけ
ることができる。たとえば多次元表用のビット・マップ
を調べたら、ブロック４８が現在、多次元表によって使
用されていない（すなわちその状態が空を示す「Ｆ」で
ある）ことが分かったとする。この場合、上記新たなレ
コードをブロック４８のページに挿入する。そして、こ
のブロック４８を、そのＢＩＤを複合ブロック索引に付
加することによりセルに割り当てるとともに、各次元ブ
ロック索引に割り当てる。
コードを作成することが含まれる。挿入操作中、クラス
タリングを維持する必要がある。いま、次元値＜９９０
３，‘ＡＢ’＞を有するレコードを（図４に示すよう
な）多次元表中に挿入することを考える。まず、複合ブ
ロック索引を使ってこの新たなレコード用に適切なブロ
ックを特定する必要がある。それには、（図５に示すよ
うな）複合ブロック索引でキー値「９９０３，ＡＢ」を
探す。その結果、次に示すキーが見つかる。 ＜９９０３，ＡＢ：３，１０＞ この場合、キー値「９９０３，ＡＢ」を有するブロック
はブロック３とブロック１０の２つあることが分かる。
これらのブロックは指定した次元を有するレコードをす
べて含んでいるが、それら以外のレコードは含んでいな
い。したがって、これらのブロックのページのいずれか
にスペースがある場合、これらのブロックのうちの１つ
に新たなレコードを挿入する。これらのブロックのペー
ジのいずれにもスペースがない場合には、多次元表に新
たなブロックを割り当てるか、多次元表中の以前に空に
したブロックを使用する。その際、（図８に示すよう
な）ブロック・マップを探索して空のブロックを見つけ
ることができる。たとえば多次元表用のビット・マップ
を調べたら、ブロック４８が現在、多次元表によって使
用されていない（すなわちその状態が空を示す「Ｆ」で
ある）ことが分かったとする。この場合、上記新たなレ
コードをブロック４８のページに挿入する。そして、こ
のブロック４８を、そのＢＩＤを複合ブロック索引に付
加することによりセルに割り当てるとともに、各次元ブ
ロック索引に割り当てる。
【００５８】結果として得られる次元ブロック索引中の
キーは次に示すようになる。 ＜９９０３：３，４，１０，１６，２０，２２，２６，
３０，３６，４８＞ ＜ＡＢ：１，３，５，６，７，８，１０，１２，１４，
３２，４８＞ 結果として得られる複合ブロック索引中のキーは次に示
すようになる。 ＜９９０３，ＡＢ：３，１０，４８＞
キーは次に示すようになる。 ＜９９０３：３，４，１０，１６，２０，２２，２６，
３０，３６，４８＞ ＜ＡＢ：１，３，５，６，７，８，１０，１２，１４，
３２，４８＞ 結果として得られる複合ブロック索引中のキーは次に示
すようになる。 ＜９９０３，ＡＢ：３，１０，４８＞
【００５９】いま、多次元表中に空のブロックがないと
する。この場合には、多次元表に新たなブロックを割り
当て、行（すなわちレコード）を挿入するのに使う。こ
の場合にも、上述したようにして索引群を更新する。
する。この場合には、多次元表に新たなブロックを割り
当て、行（すなわちレコード）を挿入するのに使う。こ
の場合にも、上述したようにして索引群を更新する。
【００６０】新たな次元を有するレコードを挿入する場
合には、新たなブロックまたは空のブロックを割り当て
なければならない。そして、次元ブロック索引と複合ブ
ロック索引に新たなキー値を付加する。
合には、新たなブロックまたは空のブロックを割り当て
なければならない。そして、次元ブロック索引と複合ブ
ロック索引に新たなキー値を付加する。
【００６１】挿入機能を実行する際には、第１レコード
をブロックに挿入するときに特に注意するのに加え、第
１レコードをブロック中の新たなページに挿入するとき
にも特別の注意を払う必要がある。それには、各ブロッ
ク用のページ・ビット・マップを使ってブロック中のペ
ージの状態を保守する。そして、ページに第１レコード
が挿入されたら、ページ・ビット・マップ中のビットを
セットする。このページ・ビット・マップによって、ブ
ロック中のページの占有状態を追跡することが可能にな
るとともに、挿入操作や削除操作の際にブロックの状態
を保守することが可能になる。
をブロックに挿入するときに特に注意するのに加え、第
１レコードをブロック中の新たなページに挿入するとき
にも特別の注意を払う必要がある。それには、各ブロッ
ク用のページ・ビット・マップを使ってブロック中のペ
ージの状態を保守する。そして、ページに第１レコード
が挿入されたら、ページ・ビット・マップ中のビットを
セットする。このページ・ビット・マップによって、ブ
ロック中のページの占有状態を追跡することが可能にな
るとともに、挿入操作や削除操作の際にブロックの状態
を保守することが可能になる。
【００６２】〔削除機能９０４〕通常の表の削除操作で
は表中の少なくとも１つのレコードを削除し、削除した
レコードが占有していたスペースを解放する。多次元表
の削除でも同じことを行なう。しかしながら、ブロック
中のページの状態に加え、ブロック全体にも特に注意す
る必要がある。ページの最終レコードを削除する場合に
は、ページ・ビット・マップを更新し削除した特定のペ
ージに付随するビットをクリア（消去）する。ブロック
中のページがすべて空の場合には、このページ・ビット
・マップを完全にクリアする。このことは当該ブロック
をブロック・マップ中で空とマーク付けしうることを示
している。この空のブロックは、たとえば将来の挿入操
作やロード操作によって再利用しうる。あるブロックを
空にしたら、次元索引もすべて更新し、当該空にしたブ
ロックに付随するＢＩＤを当該ブロックの次元属性に対
応する特定のキーから除去する。
は表中の少なくとも１つのレコードを削除し、削除した
レコードが占有していたスペースを解放する。多次元表
の削除でも同じことを行なう。しかしながら、ブロック
中のページの状態に加え、ブロック全体にも特に注意す
る必要がある。ページの最終レコードを削除する場合に
は、ページ・ビット・マップを更新し削除した特定のペ
ージに付随するビットをクリア（消去）する。ブロック
中のページがすべて空の場合には、このページ・ビット
・マップを完全にクリアする。このことは当該ブロック
をブロック・マップ中で空とマーク付けしうることを示
している。この空のブロックは、たとえば将来の挿入操
作やロード操作によって再利用しうる。あるブロックを
空にしたら、次元索引もすべて更新し、当該空にしたブ
ロックに付随するＢＩＤを当該ブロックの次元属性に対
応する特定のキーから除去する。
【００６３】〔パージ機能９０５〕パージとは、関係す
るレコードから成る大集合を削除するときに使用する特
別な形の削除操作である。いま、次に示すＳＱＬステー
トメントを考える。 Delete from Table ＿1 where color='Red' 色（color)属性は（図６に示す多次元表の場合のよう
に）この多次元表（Table＿1)の１つの次元であると仮
定する。したがって、「色が『赤』である」（color='R
ed')という制約は「赤」（Red)値に付随するブロックを
すべて削除すべきことを示している。これを実行するに
は、色の次元ブロック索引で「赤」を検索し、付随する
ＢＩＤのリストを見つけ出せばよい。このリストが「１
２、１７、２１、３０」であると仮定する。この多次元
表（Table ＿1)にこの他に索引や関係するデータ構造が
ない場合、これらのブロックを当該多次元表のブロック
・マップ中で空とマーク付けしたのち、ブロック索引か
ら上記ＢＩＤを削除することができる。これはきわめて
高速の操作であるとともに、ログをとるコストと索引を
保守するコストを低減することもできる。
るレコードから成る大集合を削除するときに使用する特
別な形の削除操作である。いま、次に示すＳＱＬステー
トメントを考える。 Delete from Table ＿1 where color='Red' 色（color)属性は（図６に示す多次元表の場合のよう
に）この多次元表（Table＿1)の１つの次元であると仮
定する。したがって、「色が『赤』である」（color='R
ed')という制約は「赤」（Red)値に付随するブロックを
すべて削除すべきことを示している。これを実行するに
は、色の次元ブロック索引で「赤」を検索し、付随する
ＢＩＤのリストを見つけ出せばよい。このリストが「１
２、１７、２１、３０」であると仮定する。この多次元
表（Table ＿1)にこの他に索引や関係するデータ構造が
ない場合、これらのブロックを当該多次元表のブロック
・マップ中で空とマーク付けしたのち、ブロック索引か
ら上記ＢＩＤを削除することができる。これはきわめて
高速の操作であるとともに、ログをとるコストと索引を
保守するコストを低減することもできる。
【００６４】パージ型の削除が適用できることを検出す
るには、削除ステートメントを検査しその中の制約が少
なくとも１つの次元文節に基づいてることを検証すれば
よい。特に、処理する必要のあるＢＩＤの集合を特定す
るのに少なくとも１つのブロック索引を用いている場合
には、パージ型の削除を使用することを考慮してもよ
い。最適化プログラムはこれを検出し、それに従った適
切な照会計画を作成することができる。留意点を挙げる
と、最適化プログラムは高速パージを可能にする（また
は不可能にする）新たな課題にも気づくことになる。こ
れらの課題は当該多次元表に別の索引や制約があるとい
うことを意味している。
るには、削除ステートメントを検査しその中の制約が少
なくとも１つの次元文節に基づいてることを検証すれば
よい。特に、処理する必要のあるＢＩＤの集合を特定す
るのに少なくとも１つのブロック索引を用いている場合
には、パージ型の削除を使用することを考慮してもよ
い。最適化プログラムはこれを検出し、それに従った適
切な照会計画を作成することができる。留意点を挙げる
と、最適化プログラムは高速パージを可能にする（また
は不可能にする）新たな課題にも気づくことになる。こ
れらの課題は当該多次元表に別の索引や制約があるとい
うことを意味している。
【００６５】〔更新機能９０６〕更新操作には表中の情
報を変更することが含まれる。多次元表では、更新には
次に示す２種類のものがある。
報を変更することが含まれる。多次元表では、更新には
次に示す２種類のものがある。
【００６６】（１）単純更新：この場合、更新は多次元
表中の次元ではない、属性すなわちフィールドにのみ適
用される。したがって、行（すなわちレコード）は同じ
論理セルに継続して属す。行は変化が生じても新たなス
ペースが必要とならない限り、同じ場所に存在し続け
る。あるいは、行は同じブロック中の新たな場所または
別のブロックに移動する可能性もある。このレコード
（すなわち行）を移動させたときには、元の場所のＲＩ
Ｄはそのままにしておき、オーバーフロー・ポインタ手
法を使って新たな場所を指示するようにする。（オーバ
ーフロー・ポインタ手法とは旧レコードが満杯になり新
レコードを作ったとき、旧レコードの末尾に新レコード
の場所を指示するポインタを格納しておく手法のことで
ある。）新たな場所が新たなブロックである場合には、
次元ブロック索引に当該新たなブロックを挿入する必要
がある。
表中の次元ではない、属性すなわちフィールドにのみ適
用される。したがって、行（すなわちレコード）は同じ
論理セルに継続して属す。行は変化が生じても新たなス
ペースが必要とならない限り、同じ場所に存在し続け
る。あるいは、行は同じブロック中の新たな場所または
別のブロックに移動する可能性もある。このレコード
（すなわち行）を移動させたときには、元の場所のＲＩ
Ｄはそのままにしておき、オーバーフロー・ポインタ手
法を使って新たな場所を指示するようにする。（オーバ
ーフロー・ポインタ手法とは旧レコードが満杯になり新
レコードを作ったとき、旧レコードの末尾に新レコード
の場所を指示するポインタを格納しておく手法のことで
ある。）新たな場所が新たなブロックである場合には、
次元ブロック索引に当該新たなブロックを挿入する必要
がある。
【００６７】（２）次元列の更新：更新が少なくとも１
つの次元列に対するものである場合、内部的にはこれを
削除と挿入として扱う必要がある。この結果、（更新対
象の次元列の）レコードは更新後は新セル中でクラスタ
化されているということが保証される。なぜなら、当該
レコードは旧セルに属すブロック中には配置できないか
らである。この操作を実行するには、上述した削除手法
と挿入手法とを組み合わせる。
つの次元列に対するものである場合、内部的にはこれを
削除と挿入として扱う必要がある。この結果、（更新対
象の次元列の）レコードは更新後は新セル中でクラスタ
化されているということが保証される。なぜなら、当該
レコードは旧セルに属すブロック中には配置できないか
らである。この操作を実行するには、上述した削除手法
と挿入手法とを組み合わせる。
【００６８】以上、添付図面を参照して本発明の説明目
的の実施形態を説明してけれども、理解すべき点を挙げ
ると、本発明はそれら明確な実施形態に限定されず、ま
た、本発明の範囲または本旨の内で当業者は他の様々な
変形および変更をなすことができる。
的の実施形態を説明してけれども、理解すべき点を挙げ
ると、本発明はそれら明確な実施形態に限定されず、ま
た、本発明の範囲または本旨の内で当業者は他の様々な
変形および変更をなすことができる。
【００６９】まとめとして以下の事項を開示する。
（１）リレーショナル・データベースにおいてクラスタ
化されたデータを効率的に保守する方法であって、前記
リレーショナル・データベースの表の少なくとも１つの
次元を少なくとも１つの表定義パラメータを用いて特定
するステップと、前記少なくとも１つの次元の各々用の
データを少なくとも１つのブロックを用いてクラスタ化
するステップと、少なくとも１つのブロック索引を作成
するステップであって、前記少なくとも１つのブロック
索引の各々が前記少なくとも１つの次元に関連付けられ
ている、ステップとを備えた方法。 （２）前記少なくとも１つのブロックの各々が連続記憶
スペースから成る、上記（１）に記載の方法。 （３）前記少なくとも１つのブロック索引の各々が、少
なくとも１つのブロックＩＤから成るリストに関連付け
られている少なくとも１つのキーを備えている、上記
（１）に記載の方法。 （４）前記少なくとも１つの次元の各々が前記表の少な
くとも１つの列に関連付けられている、上記（１）に記
載の方法。 （５）前記少なくとも１つの表定義パラメータが表作成
ステートメントまたは表変更ステートメントに関連付け
られている、上記（１）に記載の方法。 （６）前記表が多次元表である、上記（１）に記載の方
法。 （７）前記多次元表が用途情報を格納するのに使用され
ている、上記（６）に記載の方法。 （８）前記用途情報がデータウェアハウス用のものであ
る、上記（７）に記載の方法。 （９） さらに、前記多次元表用の複合次元索引を作成
するステップを備えた、上記（６）に記載の方法。 （１０）前記複合次元索引を作成するステップを自動的
に実行する、上記（９）に記載の方法。 （１１）前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、上記（９）に記載の方法。 （１２） さらに、前記表用にブロック・マップを作成
するステップを備え、前記ブロック・マップの各要素が
前記少なくとも１つのブロックの１つ用に状態情報を備
えている、上記（１）に記載の方法。 （１３）前記少なくとも１つのブロックの各々が状態情
報の複製を備えている、上記（１２）に記載の方法。 （１４）前記少なくとも１つのブロック中に備えられた
前記状態情報の複製を用いて、前記ブロック・マップを
作成する、上記（１３）に記載の方法。 （１５） さらに、前記表に格納された情報を求める照
会を処理するステップを備えた、上記（１）に記載の方
法。 （１６）前記照会を処理するステップが、前記少なくと
も１つのブロック索引および前記複合次元索引のうちの
一方の情報を用いてブロックＩＤのリストを取得するス
テップと、少なくとも１つのブロックをスキャンして少
なくとも１つの基準を満たすレコードを探し出すステッ
プであって、その際に前記ブロックＩＤのリストを用い
てスキャンすべき前記少なくとも１つのブロックを探し
出す、ステップを備えた、上記（１５）に記載の方法。 （１７）前記照会を処理するステップが、前記表全体を
スキャンして少なくとも１つの基準を満たすレコードを
探し出すステップ、および、レコード基準索引を用いて
少なくとも１つの基準を満たすレコードを探し出すステ
ップの少なくとも一方を備えた、上記（１５）に記載の
方法。 （１８）前記照会を処理するステップが、索引ＡＮＤを
備えている、上記（１５）に記載の方法。 （１９）前記照会を処理するステップが、索引ＯＲを備
えている、上記（１５）に記載の方法。 （２０）前記照会を処理するステップが、コスト・モデ
ルに基づいて照会計画を作成するステップと、前記照会
計画に従って前記照会を処理するステップとを備えてい
る、上記（１５）に記載の方法。 （２１） さらに、保守要求を処理するステップを備え
た、上記（１）に記載の方法。 （２２）前記保守要求が、ロード、再編成、挿入、削
除、パージ、および更新のうちの１つを求める要求から
成る、上記（２１）に記載の方法。 （２３）前記表のクラスタリングが、前記保守要求を処
理したあとも維持されている、上記（２１）に記載の方
法。 （２４）ロードまたは挿入を求める保守要求を処理する
前記ステップが、空のスペースが存在する場合に前記少
なくとも１つのブロックのうちの１つを使用するステッ
プ、および、空のスペースが存在しない場合に前記表に
新たなブロックを割り当てるステップのうちの一方を備
えている、上記（２２）に記載の方法。 （２５）再編成、削除、またはパージを求める保守要求
を処理する前記ステップが、スペースを再利用するステ
ップを備えている、上記（２１）に記載の方法。 （２６）機械によって読み取り可能なプログラム記憶装
置であって、前記プログラム記憶装置ちはリレーショナ
ル・データベースにおいてクラスタ化されたデータを効
率的に保守する方法を実行する、前記機械で実行可能な
命令群から成るプログラムが有形的に記録されており、
前記方法が、前記リレーショナル・データベースの表の
少なくとも１つの次元を少なくとも１つの表定義パラメ
ータを用いて特定するステップと、前記少なくとも１つ
の次元の各々用のデータを少なくとも１つのブロックを
用いてクラスタ化するステップと、少なくとも１つのブ
ロック索引を作成するステップであって、前記少なくと
も１つのブロック索引の各々が前記少なくとも１つの次
元に関連付けられている、ステップとを備えているプロ
グラム記憶装置。 （２７）前記少なくとも１つのブロックの各々が連続記
憶スペースから成る、上記（２６）に記載のプログラム
記憶装置。 （２８）前記少なくとも１つのブロック索引の各々が、
少なくとも１つのブロックＩＤから成るリストに関連付
けられている少なくとも１つのキーを備えている、上記
（２６）に記載のプログラム記憶装置。 （２９）前記少なくとも１つの次元の各々が前記表の少
なくとも１つの列に関連付けられている、上記（２６）
に記載のプログラム記憶装置。 （３０）前記少なくとも１つの表定義パラメータが表作
成ステートメントまたは表変更ステートメントに関連付
けられている、上記（２６）に記載のプログラム記憶装
置。 （３１）前記表が多次元表である、上記（２６）に記載
のプログラム記憶装置。 （３２）前記多次元表が用途情報を格納するのに使用さ
れている、上記（３１）に記載のプログラム記憶装置。 （３３）前記用途情報がデータウェアハウス用のもので
ある、上記（３２）に記載のプログラム記憶装置。 （３４） さらに、前記多次元表用の複合次元索引を作
成するステップを備えた、上記（３１）に記載のプログ
ラム記憶装置。 （３５）前記複合次元索引を作成するステップを自動的
に実行する、上記（３４）に記載のプログラム記憶装
置。 （３６）前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、上記（３４）に記載のプログラ
ム記憶装置。 （３７） さらに、前記表用にブロック・マップを作成
するステップを備え、前記ブロック・マップの各要素が
前記少なくとも１つのブロックの１つ用に状態情報を備
えている、上記（２６）に記載のプログラム記憶装置。 （３８）前記少なくとも１つのブロックの各々が状態情
報の複製を備えている、上記（３７）に記載のプログラ
ム記憶装置。 （３９）前記少なくとも１つのブロック中に備えられた
前記状態情報の複製を用いて、前記ブロック・マップを
作成する、上記（３８）に記載のプログラム記憶装置。 （４０） さらに、前記表に格納された情報を求める照
会を処理するステップを備えた、上記（２６）に記載の
プログラム記憶装置。 （４１）前記照会を処理するステップが、前記少なくと
も１つのブロック索引および前記複合次元索引のうちの
一方の情報を用いてブロックＩＤのリストを取得するス
テップと、少なくとも１つのブロックをスキャンして少
なくとも１つの基準を満たすレコードを探し出すステッ
プであって、その際に前記ブロックＩＤのリストを用い
てスキャンすべき前記少なくとも１つのブロックを探し
出す、ステップを備えた、上記（４０）に記載のプログ
ラム記憶装置。 （４２）前記照会を処理するステップが、前記表全体を
スキャンして少なくとも１つの基準を満たすレコードを
探し出すステップ、および、レコード基準索引を用いて
少なくとも１つの基準を満たすレコードを探し出すステ
ップの少なくとも一方を備えた、上記（４０）に記載の
プログラム記憶装置。 （４３）前記照会を処理するステップが、索引ＡＮＤを
備えている、上記（４０）に記載のプログラム記憶装
置。 （４４）前記照会を処理するステップが、索引ＯＲを備
えている、上記（４０）に記載のプログラム記憶装置。 （４５）前記照会を処理するステップが、コスト・モデ
ルに基づいて照会計画を作成するステップと、前記照会
計画に従って前記照会を処理するステップとを備えてい
る、上記（４０）に記載のプログラム記憶装置。 （４６） さらに、保守要求を処理するステップを備え
た、上記（２６）に記載のプログラム記憶装置。 （４７）前記保守要求が、ロード、再編成、挿入、削
除、パージ、および更新のうちの１つを求める要求から
成る、上記（４６）に記載のプログラム記憶装置。 （４８）前記表のクラスタリングが、前記保守要求を処
理したあとも維持されている、上記（４６）に記載のプ
ログラム記憶装置。 （４９）ロードまたは挿入を求める保守要求を処理する
前記ステップが、空のスペースが存在する場合に前記少
なくとも１つのブロックのうちの１つを使用するステッ
プ、および、空のスペースが存在しない場合に前記表に
新たなブロックを割り当てるステップのうちの一方を備
えている、上記（４７）に記載のプログラム記憶装置。 （５０）再編成、削除、またはパージを求める保守要求
を処理する前記ステップが、スペースを再利用するステ
ップを備えている、上記（４６）に記載のプログラム記
憶装置。
化されたデータを効率的に保守する方法であって、前記
リレーショナル・データベースの表の少なくとも１つの
次元を少なくとも１つの表定義パラメータを用いて特定
するステップと、前記少なくとも１つの次元の各々用の
データを少なくとも１つのブロックを用いてクラスタ化
するステップと、少なくとも１つのブロック索引を作成
するステップであって、前記少なくとも１つのブロック
索引の各々が前記少なくとも１つの次元に関連付けられ
ている、ステップとを備えた方法。 （２）前記少なくとも１つのブロックの各々が連続記憶
スペースから成る、上記（１）に記載の方法。 （３）前記少なくとも１つのブロック索引の各々が、少
なくとも１つのブロックＩＤから成るリストに関連付け
られている少なくとも１つのキーを備えている、上記
（１）に記載の方法。 （４）前記少なくとも１つの次元の各々が前記表の少な
くとも１つの列に関連付けられている、上記（１）に記
載の方法。 （５）前記少なくとも１つの表定義パラメータが表作成
ステートメントまたは表変更ステートメントに関連付け
られている、上記（１）に記載の方法。 （６）前記表が多次元表である、上記（１）に記載の方
法。 （７）前記多次元表が用途情報を格納するのに使用され
ている、上記（６）に記載の方法。 （８）前記用途情報がデータウェアハウス用のものであ
る、上記（７）に記載の方法。 （９） さらに、前記多次元表用の複合次元索引を作成
するステップを備えた、上記（６）に記載の方法。 （１０）前記複合次元索引を作成するステップを自動的
に実行する、上記（９）に記載の方法。 （１１）前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、上記（９）に記載の方法。 （１２） さらに、前記表用にブロック・マップを作成
するステップを備え、前記ブロック・マップの各要素が
前記少なくとも１つのブロックの１つ用に状態情報を備
えている、上記（１）に記載の方法。 （１３）前記少なくとも１つのブロックの各々が状態情
報の複製を備えている、上記（１２）に記載の方法。 （１４）前記少なくとも１つのブロック中に備えられた
前記状態情報の複製を用いて、前記ブロック・マップを
作成する、上記（１３）に記載の方法。 （１５） さらに、前記表に格納された情報を求める照
会を処理するステップを備えた、上記（１）に記載の方
法。 （１６）前記照会を処理するステップが、前記少なくと
も１つのブロック索引および前記複合次元索引のうちの
一方の情報を用いてブロックＩＤのリストを取得するス
テップと、少なくとも１つのブロックをスキャンして少
なくとも１つの基準を満たすレコードを探し出すステッ
プであって、その際に前記ブロックＩＤのリストを用い
てスキャンすべき前記少なくとも１つのブロックを探し
出す、ステップを備えた、上記（１５）に記載の方法。 （１７）前記照会を処理するステップが、前記表全体を
スキャンして少なくとも１つの基準を満たすレコードを
探し出すステップ、および、レコード基準索引を用いて
少なくとも１つの基準を満たすレコードを探し出すステ
ップの少なくとも一方を備えた、上記（１５）に記載の
方法。 （１８）前記照会を処理するステップが、索引ＡＮＤを
備えている、上記（１５）に記載の方法。 （１９）前記照会を処理するステップが、索引ＯＲを備
えている、上記（１５）に記載の方法。 （２０）前記照会を処理するステップが、コスト・モデ
ルに基づいて照会計画を作成するステップと、前記照会
計画に従って前記照会を処理するステップとを備えてい
る、上記（１５）に記載の方法。 （２１） さらに、保守要求を処理するステップを備え
た、上記（１）に記載の方法。 （２２）前記保守要求が、ロード、再編成、挿入、削
除、パージ、および更新のうちの１つを求める要求から
成る、上記（２１）に記載の方法。 （２３）前記表のクラスタリングが、前記保守要求を処
理したあとも維持されている、上記（２１）に記載の方
法。 （２４）ロードまたは挿入を求める保守要求を処理する
前記ステップが、空のスペースが存在する場合に前記少
なくとも１つのブロックのうちの１つを使用するステッ
プ、および、空のスペースが存在しない場合に前記表に
新たなブロックを割り当てるステップのうちの一方を備
えている、上記（２２）に記載の方法。 （２５）再編成、削除、またはパージを求める保守要求
を処理する前記ステップが、スペースを再利用するステ
ップを備えている、上記（２１）に記載の方法。 （２６）機械によって読み取り可能なプログラム記憶装
置であって、前記プログラム記憶装置ちはリレーショナ
ル・データベースにおいてクラスタ化されたデータを効
率的に保守する方法を実行する、前記機械で実行可能な
命令群から成るプログラムが有形的に記録されており、
前記方法が、前記リレーショナル・データベースの表の
少なくとも１つの次元を少なくとも１つの表定義パラメ
ータを用いて特定するステップと、前記少なくとも１つ
の次元の各々用のデータを少なくとも１つのブロックを
用いてクラスタ化するステップと、少なくとも１つのブ
ロック索引を作成するステップであって、前記少なくと
も１つのブロック索引の各々が前記少なくとも１つの次
元に関連付けられている、ステップとを備えているプロ
グラム記憶装置。 （２７）前記少なくとも１つのブロックの各々が連続記
憶スペースから成る、上記（２６）に記載のプログラム
記憶装置。 （２８）前記少なくとも１つのブロック索引の各々が、
少なくとも１つのブロックＩＤから成るリストに関連付
けられている少なくとも１つのキーを備えている、上記
（２６）に記載のプログラム記憶装置。 （２９）前記少なくとも１つの次元の各々が前記表の少
なくとも１つの列に関連付けられている、上記（２６）
に記載のプログラム記憶装置。 （３０）前記少なくとも１つの表定義パラメータが表作
成ステートメントまたは表変更ステートメントに関連付
けられている、上記（２６）に記載のプログラム記憶装
置。 （３１）前記表が多次元表である、上記（２６）に記載
のプログラム記憶装置。 （３２）前記多次元表が用途情報を格納するのに使用さ
れている、上記（３１）に記載のプログラム記憶装置。 （３３）前記用途情報がデータウェアハウス用のもので
ある、上記（３２）に記載のプログラム記憶装置。 （３４） さらに、前記多次元表用の複合次元索引を作
成するステップを備えた、上記（３１）に記載のプログ
ラム記憶装置。 （３５）前記複合次元索引を作成するステップを自動的
に実行する、上記（３４）に記載のプログラム記憶装
置。 （３６）前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、上記（３４）に記載のプログラ
ム記憶装置。 （３７） さらに、前記表用にブロック・マップを作成
するステップを備え、前記ブロック・マップの各要素が
前記少なくとも１つのブロックの１つ用に状態情報を備
えている、上記（２６）に記載のプログラム記憶装置。 （３８）前記少なくとも１つのブロックの各々が状態情
報の複製を備えている、上記（３７）に記載のプログラ
ム記憶装置。 （３９）前記少なくとも１つのブロック中に備えられた
前記状態情報の複製を用いて、前記ブロック・マップを
作成する、上記（３８）に記載のプログラム記憶装置。 （４０） さらに、前記表に格納された情報を求める照
会を処理するステップを備えた、上記（２６）に記載の
プログラム記憶装置。 （４１）前記照会を処理するステップが、前記少なくと
も１つのブロック索引および前記複合次元索引のうちの
一方の情報を用いてブロックＩＤのリストを取得するス
テップと、少なくとも１つのブロックをスキャンして少
なくとも１つの基準を満たすレコードを探し出すステッ
プであって、その際に前記ブロックＩＤのリストを用い
てスキャンすべき前記少なくとも１つのブロックを探し
出す、ステップを備えた、上記（４０）に記載のプログ
ラム記憶装置。 （４２）前記照会を処理するステップが、前記表全体を
スキャンして少なくとも１つの基準を満たすレコードを
探し出すステップ、および、レコード基準索引を用いて
少なくとも１つの基準を満たすレコードを探し出すステ
ップの少なくとも一方を備えた、上記（４０）に記載の
プログラム記憶装置。 （４３）前記照会を処理するステップが、索引ＡＮＤを
備えている、上記（４０）に記載のプログラム記憶装
置。 （４４）前記照会を処理するステップが、索引ＯＲを備
えている、上記（４０）に記載のプログラム記憶装置。 （４５）前記照会を処理するステップが、コスト・モデ
ルに基づいて照会計画を作成するステップと、前記照会
計画に従って前記照会を処理するステップとを備えてい
る、上記（４０）に記載のプログラム記憶装置。 （４６） さらに、保守要求を処理するステップを備え
た、上記（２６）に記載のプログラム記憶装置。 （４７）前記保守要求が、ロード、再編成、挿入、削
除、パージ、および更新のうちの１つを求める要求から
成る、上記（４６）に記載のプログラム記憶装置。 （４８）前記表のクラスタリングが、前記保守要求を処
理したあとも維持されている、上記（４６）に記載のプ
ログラム記憶装置。 （４９）ロードまたは挿入を求める保守要求を処理する
前記ステップが、空のスペースが存在する場合に前記少
なくとも１つのブロックのうちの１つを使用するステッ
プ、および、空のスペースが存在しない場合に前記表に
新たなブロックを割り当てるステップのうちの一方を備
えている、上記（４７）に記載のプログラム記憶装置。 （５０）再編成、削除、またはパージを求める保守要求
を処理する前記ステップが、スペースを再利用するステ
ップを備えている、上記（４６）に記載のプログラム記
憶装置。
【図１】 本発明の手法で用いる典型的な環境のブロッ
ク図である。
ク図である。
【図２】 本発明に係る典型的なリレーショナル・デー
タベース管理システムの模式図である。
タベース管理システムの模式図である。
【図３】 本発明の一実施形態に係る２次元にクラスタ
化した典型的な多次元表の模式図である。
化した典型的な多次元表の模式図である。
【図４】 本発明の一実施形態に係り図３の典型的な多
次元表に各次元に関する次元索引を備えたものの模式図
である。
次元表に各次元に関する次元索引を備えたものの模式図
である。
【図５】 本発明の一実施形態に係る典型的な複合次元
索引の模式図である。
索引の模式図である。
【図６】 本発明の一実施形態に係り図３の典型的な多
次元表を第３の次元に拡張したものの模式図である。
次元表を第３の次元に拡張したものの模式図である。
【図７】 （ａ）〜（ｃ）は本発明の一実施形態に係る
索引ＡＮＤ手法の模式図である。
索引ＡＮＤ手法の模式図である。
【図８】 本発明の一実施形態に係る典型的なブロック
・マップの模式図である。
・マップの模式図である。
【図９】 本発明の一実施形態に係る様々な典型的な保
守機能の模式図である。
守機能の模式図である。
１００ システム
１０１ メモリ
１０２ プロセッサ
１０３ ＲＤＢＭＳ
１０４ 入出力（Ｉ／Ｏ）装置
２０１ 照会コンパイラ
２０２ コード・ジェネレータ
２０３ 実行エンジン
２０４ アクセス・メソッド・エンジン
２０５ バッファ・マネージャ
２０６ ユーティリティ・エンジン
２０７ データ・マネージャ
２０８ 残余コンポーネント
３００ 年月次元
３０１ 長円（ブロック）
３０２ 正方形（セル）
３１０ 州次元
４００ 次元ブロック索引
４１０ 次元ブロック索引
６００ 色次元
７１５ スライス
７２５ スライス
７３５ 区画
９００ 保守機能
９０１ ロード機能
９０２ 再編成機能
９０３ 挿入機能
９０４ 削除機能
９０５ パージ機能
９０６ 更新機能
─────────────────────────────────────────────────────
フロントページの続き
(72)発明者 ラメッシュ・シー・アガワル
アメリカ合衆国 カリフォルニア州
95014、クパチーノ、ペラルタ コート
10512
(72)発明者 ビッシュワランジャン・バタシャルジー
アメリカ合衆国 ニューヨーク州 10598、
ヨークタウン ハイツ、ホリー ドライブ
2846
(72)発明者 レズリー・エイ・クランストン
カナダ国 オンタリオ州 エム・４・エス
２・ティー・２、トロント、ボイトン
ロード 24
(72)発明者 マシュー・エイ・フラス
カナダ国 オンタリオ州 エル・１・ティ
ー ３・エヌ・４、アジャックス、タリフ
センター 15
(72)発明者 トニー・ウェン・スン・ライ
カナダ国 オンタリオ州 エム・４・ワイ
２・エックス・６、トロント、ウェルズ
リー ストリート ウエスト 1113−24
(72)発明者 ティモシー・アール・モーキマス
アメリカ合衆国 テキサス州 78681、ラ
ウンド ロック、ロック クリーク ドラ
イブ 1602
(72)発明者 スリラム・ケー・パドマナバン
アメリカ合衆国 ニューヨーク州 10510、
ブライアークリフ メイナー、インガム
ロード ４
Ｆターム(参考） 5B075 ND40 NK50 NR03 NR20 QS20
QT06
5B082 GA03
Claims (50)
- 【請求項１】リレーショナル・データベースにおいてク
ラスタ化されたデータを効率的に保守する方法であっ
て、 前記リレーショナル・データベースの表の少なくとも１
つの次元を少なくとも１つの表定義パラメータを用いて
特定するステップと、 前記少なくとも１つの次元の各々用のデータを少なくと
も１つのブロックを用いてクラスタ化するステップと、 少なくとも１つのブロック索引を作成するステップであ
って、前記少なくとも１つのブロック索引の各々が前記
少なくとも１つの次元に関連付けられている、ステップ
とを備えた方法。 - 【請求項２】前記少なくとも１つのブロックの各々が連
続記憶スペースから成る、請求項１に記載の方法。 - 【請求項３】前記少なくとも１つのブロック索引の各々
が、少なくとも１つのブロックＩＤから成るリストに関
連付けられている少なくとも１つのキーを備えている、
請求項１に記載の方法。 - 【請求項４】前記少なくとも１つの次元の各々が前記表
の少なくとも１つの列に関連付けられている、請求項１
に記載の方法。 - 【請求項５】前記少なくとも１つの表定義パラメータが
表作成ステートメントまたは表変更ステートメントに関
連付けられている、請求項１に記載の方法。 - 【請求項６】前記表が多次元表である、請求項１に記載
の方法。 - 【請求項７】前記多次元表が用途情報を格納するのに使
用されている、請求項６に記載の方法。 - 【請求項８】前記用途情報がデータウェアハウス用のも
のである、請求項７に記載の方法。 - 【請求項９】 さらに、 前記多次元表用の複合次元索引を作成するステップを備
えた、請求項６に記載の方法。 - 【請求項１０】前記複合次元索引を作成するステップを
自動的に実行する、請求項９に記載の方法。 - 【請求項１１】前記複合次元索引が複合キーのリストを
備え、 各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、請求項９に記載の方法。 - 【請求項１２】 さらに、 前記表用にブロック・マップを作成するステップを備
え、 前記ブロック・マップの各要素が前記少なくとも１つの
ブロックの１つ用に状態情報を備えている、請求項１に
記載の方法。 - 【請求項１３】前記少なくとも１つのブロックの各々が
状態情報の複製を備えている、請求項１２に記載の方
法。 - 【請求項１４】前記少なくとも１つのブロック中に備え
られた前記状態情報の複製を用いて、前記ブロック・マ
ップを作成する、請求項１３に記載の方法。 - 【請求項１５】 さらに、 前記表に格納された情報を求める照会を処理するステッ
プを備えた、請求項１に記載の方法。 - 【請求項１６】前記照会を処理するステップが、 前記少なくとも１つのブロック索引および前記複合次元
索引のうちの一方の情報を用いてブロックＩＤのリスト
を取得するステップと、 少なくとも１つのブロックをスキャンして少なくとも１
つの基準を満たすレコードを探し出すステップであっ
て、その際に前記ブロックＩＤのリストを用いてスキャ
ンすべき前記少なくとも１つのブロックを探し出す、ス
テップを備えた、請求項１５に記載の方法。 - 【請求項１７】前記照会を処理するステップが、 前記表全体をスキャンして少なくとも１つの基準を満た
すレコードを探し出すステップ、および、 レコード基準索引を用いて少なくとも１つの基準を満た
すレコードを探し出すステップの少なくとも一方を備え
た、請求項１５に記載の方法。 - 【請求項１８】前記照会を処理するステップが、 索引ＡＮＤを備えている、請求項１５に記載の方法。
- 【請求項１９】前記照会を処理するステップが、 索引ＯＲを備えている、請求項１５に記載の方法。
- 【請求項２０】前記照会を処理するステップが、 コスト・モデルに基づいて照会計画を作成するステップ
と、 前記照会計画に従って前記照会を処理するステップとを
備えている、請求項１５に記載の方法。 - 【請求項２１】 さらに、 保守要求を処理するステップを備えた、請求項１に記載
の方法。 - 【請求項２２】前記保守要求が、 ロード、再編成、挿入、削除、パージ、および更新のう
ちの１つを求める要求から成る、請求項２１に記載の方
法。 - 【請求項２３】前記表のクラスタリングが、前記保守要
求を処理したあとも維持されている、請求項２１に記載
の方法。 - 【請求項２４】ロードまたは挿入を求める保守要求を処
理する前記ステップが、 空のスペースが存在する場合に前記少なくとも１つのブ
ロックのうちの１つを使用するステップ、および、 空のスペースが存在しない場合に前記表に新たなブロッ
クを割り当てるステップのうちの一方を備えている、請
求項２２に記載の方法。 - 【請求項２５】再編成、削除、またはパージを求める保
守要求を処理する前記ステップが、 スペースを再利用するステップを備えている、請求項２
１に記載の方法。 - 【請求項２６】機械によって読み取り可能なプログラム
記憶装置であって、前記プログラム記憶装置ちはリレー
ショナル・データベースにおいてクラスタ化されたデー
タを効率的に保守する方法を実行する、前記機械で実行
可能な命令群から成るプログラムが有形的に記録されて
おり、前記方法が、 前記リレーショナル・データベースの表の少なくとも１
つの次元を少なくとも１つの表定義パラメータを用いて
特定するステップと、 前記少なくとも１つの次元の各々用のデータを少なくと
も１つのブロックを用いてクラスタ化するステップと、 少なくとも１つのブロック索引を作成するステップであ
って、前記少なくとも１つのブロック索引の各々が前記
少なくとも１つの次元に関連付けられている、ステップ
とを備えているプログラム記憶装置。 - 【請求項２７】前記少なくとも１つのブロックの各々が
連続記憶スペースから成る、請求項２６に記載のプログ
ラム記憶装置。 - 【請求項２８】前記少なくとも１つのブロック索引の各
々が、少なくとも１つのブロックＩＤから成るリストに
関連付けられている少なくとも１つのキーを備えてい
る、請求項２６に記載のプログラム記憶装置。 - 【請求項２９】前記少なくとも１つの次元の各々が前記
表の少なくとも１つの列に関連付けられている、請求項
２６に記載のプログラム記憶装置。 - 【請求項３０】前記少なくとも１つの表定義パラメータ
が表作成ステートメントまたは表変更ステートメントに
関連付けられている、請求項２６に記載のプログラム記
憶装置。 - 【請求項３１】前記表が多次元表である、請求項２６に
記載のプログラム記憶装置。 - 【請求項３２】前記多次元表が用途情報を格納するのに
使用されている、請求項３１に記載のプログラム記憶装
置。 - 【請求項３３】前記用途情報がデータウェアハウス用の
ものである、請求項３２に記載のプログラム記憶装置。 - 【請求項３４】 さらに、 前記多次元表用の複合次元索引を作成するステップを備
えた、請求項３１に記載のプログラム記憶装置。 - 【請求項３５】前記複合次元索引を作成するステップを
自動的に実行する、請求項３４に記載のプログラム記憶
装置。 - 【請求項３６】前記複合次元索引が複合キーのリストを
備え、 各複合キーが前記多次元表のセルに関連付けられている
とともに、前記セル用に少なくとも１つのブロックＩＤ
のリストを備えている、請求項３４に記載のプログラム
記憶装置。 - 【請求項３７】 さらに、 前記表用にブロック・マップを作成するステップを備
え、 前記ブロック・マップの各要素が前記少なくとも１つの
ブロックの１つ用に状態情報を備えている、請求項２６
に記載のプログラム記憶装置。 - 【請求項３８】前記少なくとも１つのブロックの各々が
状態情報の複製を備えている、請求項３７に記載のプロ
グラム記憶装置。 - 【請求項３９】前記少なくとも１つのブロック中に備え
られた前記状態情報の複製を用いて、前記ブロック・マ
ップを作成する、請求項３８に記載のプログラム記憶装
置。 - 【請求項４０】 さらに、 前記表に格納された情報を求める照会を処理するステッ
プを備えた、請求項２６に記載のプログラム記憶装置。 - 【請求項４１】前記照会を処理するステップが、 前記少なくとも１つのブロック索引および前記複合次元
索引のうちの一方の情報を用いてブロックＩＤのリスト
を取得するステップと、 少なくとも１つのブロックをスキャンして少なくとも１
つの基準を満たすレコードを探し出すステップであっ
て、その際に前記ブロックＩＤのリストを用いてスキャ
ンすべき前記少なくとも１つのブロックを探し出す、ス
テップを備えた、請求項４０に記載のプログラム記憶装
置。 - 【請求項４２】前記照会を処理するステップが、 前記表全体をスキャンして少なくとも１つの基準を満た
すレコードを探し出すステップ、および、 レコード基準索引を用いて少なくとも１つの基準を満た
すレコードを探し出すステップの少なくとも一方を備え
た、請求項４０に記載のプログラム記憶装置。 - 【請求項４３】前記照会を処理するステップが、 索引ＡＮＤを備えている、請求項４０に記載のプログラ
ム記憶装置。 - 【請求項４４】前記照会を処理するステップが、 索引ＯＲを備えている、請求項４０に記載のプログラム
記憶装置。 - 【請求項４５】前記照会を処理するステップが、 コスト・モデルに基づいて照会計画を作成するステップ
と、 前記照会計画に従って前記照会を処理するステップとを
備えている、請求項４０に記載のプログラム記憶装置。 - 【請求項４６】 さらに、 保守要求を処理するステップを備えた、請求項２６に記
載のプログラム記憶装置。 - 【請求項４７】前記保守要求が、 ロード、再編成、挿入、削除、パージ、および更新のう
ちの１つを求める要求から成る、請求項４６に記載のプ
ログラム記憶装置。 - 【請求項４８】前記表のクラスタリングが、前記保守要
求を処理したあとも維持されている、請求項４６に記載
のプログラム記憶装置。 - 【請求項４９】ロードまたは挿入を求める保守要求を処
理する前記ステップが、 空のスペースが存在する場合に前記少なくとも１つのブ
ロックのうちの１つを使用するステップ、および、 空のスペースが存在しない場合に前記表に新たなブロッ
クを割り当てるステップのうちの一方を備えている、請
求項４７に記載のプログラム記憶装置。 - 【請求項５０】再編成、削除、またはパージを求める保
守要求を処理する前記ステップが、 スペースを再利用するステップを備えている、請求項４
６に記載のプログラム記憶装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/122,502 US7080081B2 (en) | 2002-04-15 | 2002-04-15 | Multidimensional data clustering scheme for query processing and maintenance in relational databases |
| US10/122502 | 2002-04-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003330964A true JP2003330964A (ja) | 2003-11-21 |
| JP3945771B2 JP3945771B2 (ja) | 2007-07-18 |
Family
ID=28790556
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003100031A Expired - Fee Related JP3945771B2 (ja) | 2002-04-15 | 2003-04-03 | データベース・システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7080081B2 (ja) |
| JP (1) | JP3945771B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6192781B1 (ja) * | 2016-07-26 | 2017-09-06 | 三菱電機株式会社 | データ管理プログラム及びデータ管理装置 |
Families Citing this family (79)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6778824B2 (en) * | 2002-06-19 | 2004-08-17 | Telular Corp. | Apparatus for wirelessly-coupling a bluetooth-wireless cellular mobile handset to a docking station for connecting a standard telephone set to the cellular network |
| US7765211B2 (en) * | 2003-04-29 | 2010-07-27 | International Business Machines Corporation | System and method for space management of multidimensionally clustered tables |
| US7480662B2 (en) * | 2003-07-03 | 2009-01-20 | Oracle International Corporation | Fact table storage in a decision support system environment |
| US7734661B2 (en) * | 2003-08-11 | 2010-06-08 | Descisys Limited | Method and apparatus for accessing multidimensional data |
| US8315972B2 (en) * | 2003-09-26 | 2012-11-20 | Microsoft Corporation | Method for maintaining databases information about multiple instances of an activity generating, updating virtual OLAP cube based on modified star-schema |
| US8108429B2 (en) | 2004-05-07 | 2012-01-31 | Quest Software, Inc. | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
| US7565661B2 (en) * | 2004-05-10 | 2009-07-21 | Siew Yong Sim-Tang | Method and system for real-time event journaling to provide enterprise data services |
| US7734581B2 (en) * | 2004-05-18 | 2010-06-08 | Oracle International Corporation | Vector reads for array updates |
| US7680834B1 (en) | 2004-06-08 | 2010-03-16 | Bakbone Software, Inc. | Method and system for no downtime resychronization for real-time, continuous data protection |
| US7979404B2 (en) | 2004-09-17 | 2011-07-12 | Quest Software, Inc. | Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data |
| US8131472B2 (en) * | 2004-09-28 | 2012-03-06 | International Business Machines Corporation | Methods for hierarchical organization of data associated with medical events in databases |
| US8892571B2 (en) | 2004-10-12 | 2014-11-18 | International Business Machines Corporation | Systems for associating records in healthcare database with individuals |
| US7904913B2 (en) | 2004-11-02 | 2011-03-08 | Bakbone Software, Inc. | Management interface for a system that provides automated, real-time, continuous data protection |
| US7580922B2 (en) * | 2005-01-04 | 2009-08-25 | International Business Machines Corporation | Methods for relating data in healthcare databases |
| US7548903B2 (en) * | 2005-01-11 | 2009-06-16 | International Business Machines Corporation | Method and apparatus for automatic recommendation and selection of clustering indexes |
| US8645313B1 (en) * | 2005-05-27 | 2014-02-04 | Microstrategy, Inc. | Systems and methods for enhanced SQL indices for duplicate row entries |
| US7788521B1 (en) | 2005-07-20 | 2010-08-31 | Bakbone Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
| US7689602B1 (en) | 2005-07-20 | 2010-03-30 | Bakbone Software, Inc. | Method of creating hierarchical indices for a distributed object system |
| US8200501B2 (en) * | 2006-01-26 | 2012-06-12 | International Business Machines Corporation | Methods, systems and computer program products for synthesizing medical procedure information in healthcare databases |
| US20070174091A1 (en) * | 2006-01-26 | 2007-07-26 | International Business Machines Corporation | Methods, data structures, systems and computer program products for identifying obsure patterns in healthcare related data |
| US8566113B2 (en) * | 2006-02-07 | 2013-10-22 | International Business Machines Corporation | Methods, systems and computer program products for providing a level of anonymity to patient records/information |
| US7631014B2 (en) * | 2006-04-27 | 2009-12-08 | International Business Machines Corporation | Method and apparatus for fast deletion of physically clustered data |
| US20070288883A1 (en) * | 2006-06-09 | 2007-12-13 | International Business Machines Corporation | Method for consolidated launching of multiple tasks |
| US8302073B2 (en) * | 2006-06-15 | 2012-10-30 | International Business Machines Corporation | Moving and copying dependencies along with source code |
| KR101234795B1 (ko) * | 2006-06-15 | 2013-02-20 | 삼성전자주식회사 | 컨텐츠 브라우징 장치 및 방법 |
| US7870536B2 (en) * | 2006-06-15 | 2011-01-11 | International Business Machines Corporation | Computer implemented method and system for sharing resources among hierarchical containers of resources |
| US7519583B2 (en) * | 2006-07-14 | 2009-04-14 | International Business Machines Corporation | Detecting and tracking monotonicity for accelerating range and inequality queries |
| US9202184B2 (en) | 2006-09-07 | 2015-12-01 | International Business Machines Corporation | Optimizing the selection, verification, and deployment of expert resources in a time of chaos |
| WO2008034213A1 (en) * | 2006-09-18 | 2008-03-27 | Infobright Inc. | A method and system for data compression in a relational database |
| US8266147B2 (en) * | 2006-09-18 | 2012-09-11 | Infobright, Inc. | Methods and systems for database organization |
| US9087335B2 (en) * | 2006-09-29 | 2015-07-21 | American Express Travel Related Services Company, Inc. | Multidimensional personal behavioral tomography |
| US20090287503A1 (en) * | 2008-05-16 | 2009-11-19 | International Business Machines Corporation | Analysis of individual and group healthcare data in order to provide real time healthcare recommendations |
| US8055603B2 (en) | 2006-10-03 | 2011-11-08 | International Business Machines Corporation | Automatic generation of new rules for processing synthetic events using computer-based learning processes |
| US8145582B2 (en) * | 2006-10-03 | 2012-03-27 | International Business Machines Corporation | Synthetic events for real time patient analysis |
| US20080294459A1 (en) * | 2006-10-03 | 2008-11-27 | International Business Machines Corporation | Health Care Derivatives as a Result of Real Time Patient Analytics |
| US7853611B2 (en) | 2007-02-26 | 2010-12-14 | International Business Machines Corporation | System and method for deriving a hierarchical event based database having action triggers based on inferred probabilities |
| US7970759B2 (en) | 2007-02-26 | 2011-06-28 | International Business Machines Corporation | System and method for deriving a hierarchical event based database optimized for pharmaceutical analysis |
| US7792774B2 (en) | 2007-02-26 | 2010-09-07 | International Business Machines Corporation | System and method for deriving a hierarchical event based database optimized for analysis of chaotic events |
| US8484220B2 (en) | 2007-03-06 | 2013-07-09 | Mcafee, Inc. | Clustered index with differentiated subfields |
| CA2680217C (en) * | 2007-03-06 | 2017-06-13 | Nitrosecurity, Inc. | A database system with database indexes for improved performance |
| US8131723B2 (en) | 2007-03-30 | 2012-03-06 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
| US8364648B1 (en) | 2007-04-09 | 2013-01-29 | Quest Software, Inc. | Recovering a database to any point-in-time in the past with guaranteed data consistency |
| US9043367B2 (en) * | 2007-05-23 | 2015-05-26 | Oracle International Corporation | Self-learning data lenses for conversion of information from a first form to a second form |
| US7930262B2 (en) * | 2007-10-18 | 2011-04-19 | International Business Machines Corporation | System and method for the longitudinal analysis of education outcomes using cohort life cycles, cluster analytics-based cohort analysis, and probabilistic data schemas |
| US7779051B2 (en) * | 2008-01-02 | 2010-08-17 | International Business Machines Corporation | System and method for optimizing federated and ETL'd databases with considerations of specialized data structures within an environment having multidimensional constraints |
| US8150850B2 (en) * | 2008-01-07 | 2012-04-03 | Akiban Technologies, Inc. | Multiple dimensioned database architecture |
| US20100198830A1 (en) * | 2008-03-06 | 2010-08-05 | Nitrosecurity, Inc. | Dynamic data distribution aggregation |
| US8121858B2 (en) * | 2008-03-24 | 2012-02-21 | International Business Machines Corporation | Optimizing pharmaceutical treatment plans across multiple dimensions |
| US9355165B2 (en) * | 2008-03-31 | 2016-05-31 | Paul Grant BARBER | Method and system for performing data manipulations associated with business processes and operations |
| WO2010061260A1 (en) * | 2008-11-03 | 2010-06-03 | Elvin Slavik | Method, system, and product for managing spatial data in a database |
| US8375227B2 (en) * | 2009-02-02 | 2013-02-12 | Microsoft Corporation | Abstracting programmatic representation of data storage systems |
| US8190557B2 (en) * | 2009-11-25 | 2012-05-29 | Barber Paul Grant | Processor and method configured for executing data transfer or data adjustment functions on OLAP based data |
| US8335804B2 (en) * | 2010-03-29 | 2012-12-18 | International Business Machines Corporation | Adaptive relational database access |
| US8417727B2 (en) | 2010-06-14 | 2013-04-09 | Infobright Inc. | System and method for storing data in a relational database |
| US8521748B2 (en) | 2010-06-14 | 2013-08-27 | Infobright Inc. | System and method for managing metadata in a relational database |
| US10318877B2 (en) | 2010-10-19 | 2019-06-11 | International Business Machines Corporation | Cohort-based prediction of a future event |
| US8799611B2 (en) | 2011-05-05 | 2014-08-05 | International Business Machines Corporation | Managing allocation of memory pages |
| US8793444B2 (en) | 2011-05-05 | 2014-07-29 | International Business Machines Corporation | Managing large page memory pools |
| US8683169B2 (en) | 2011-05-05 | 2014-03-25 | International Business Machines Corporation | Selecting an auxiliary storage medium for writing data of real storage pages |
| US8656133B2 (en) | 2011-05-05 | 2014-02-18 | International Business Machines Corporation | Managing storage extents and the obtaining of storage blocks within the extents |
| US8868876B2 (en) | 2011-12-28 | 2014-10-21 | International Business Machines Corporation | Dedicated large page memory pools |
| US20130304531A1 (en) | 2012-05-11 | 2013-11-14 | Paul Barber | System and method for performing detailed planning functions |
| US9514187B2 (en) | 2012-09-28 | 2016-12-06 | Oracle International Corporation | Techniques for using zone map information for post index access pruning |
| US9430550B2 (en) * | 2012-09-28 | 2016-08-30 | Oracle International Corporation | Clustering a table in a relational database management system |
| US8996544B2 (en) | 2012-09-28 | 2015-03-31 | Oracle International Corporation | Pruning disk blocks of a clustered table in a relational database management system |
| US8756237B2 (en) * | 2012-10-12 | 2014-06-17 | Architecture Technology Corporation | Scalable distributed processing of RDF data |
| US20140317082A1 (en) * | 2013-02-08 | 2014-10-23 | Michael Archuleta | System and method for providing mobile websites |
| US9256633B2 (en) | 2013-03-15 | 2016-02-09 | International Business Machines Corporation | Partitioning data for parallel processing |
| US10642837B2 (en) | 2013-03-15 | 2020-05-05 | Oracle International Corporation | Relocating derived cache during data rebalance to maintain application performance |
| US9659061B2 (en) * | 2013-05-14 | 2017-05-23 | ServiceSource | Method for efficient aggregation of numerous data using sparse bit sets |
| US9946705B2 (en) * | 2015-06-29 | 2018-04-17 | International Business Machines Corporation | Query processing using a dimension table implemented as decompression dictionaries |
| US11520760B2 (en) * | 2015-10-23 | 2022-12-06 | Oracle International Corporation | System and method for providing bottom-up aggregation in a multidimensional database environment |
| US10558636B2 (en) * | 2016-04-27 | 2020-02-11 | Sap Se | Index page with latch-free access |
| US10817540B2 (en) * | 2016-09-02 | 2020-10-27 | Snowflake Inc. | Incremental clustering maintenance of a table |
| US11086876B2 (en) | 2017-09-29 | 2021-08-10 | Oracle International Corporation | Storing derived summaries on persistent memory of a storage device |
| US10936627B2 (en) | 2017-10-27 | 2021-03-02 | Intuit, Inc. | Systems and methods for intelligently grouping financial product users into cohesive cohorts |
| US10997147B2 (en) | 2018-07-17 | 2021-05-04 | Snowflake Inc. | Incremental clustering of database tables |
| US11138213B2 (en) | 2019-04-10 | 2021-10-05 | Snowflake Inc. | Internal resource provisioning in database systems |
| CN110147372B (zh) * | 2019-05-21 | 2022-12-23 | 电子科技大学 | 一种面向htap的分布式数据库智能混合存储方法 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5041972A (en) * | 1988-04-15 | 1991-08-20 | Frost W Alan | Method of measuring and evaluating consumer response for the development of consumer products |
| DE69232542T2 (de) * | 1991-09-27 | 2002-11-21 | Bmc Software Inc | Definitionsänderungssprache für ein Datenbankrechnersystem |
| US5325445A (en) * | 1992-05-29 | 1994-06-28 | Eastman Kodak Company | Feature classification using supervised statistical pattern recognition |
| JP3952518B2 (ja) * | 1996-03-29 | 2007-08-01 | 株式会社日立製作所 | 多次元データ処理方法 |
| US5884304A (en) * | 1996-09-20 | 1999-03-16 | Novell, Inc. | Alternate key index query apparatus and method |
| US5905985A (en) * | 1997-06-30 | 1999-05-18 | International Business Machines Corporation | Relational database modifications based on multi-dimensional database modifications |
| US5943677A (en) * | 1997-10-31 | 1999-08-24 | Oracle Corporation | Sparsity management system for multi-dimensional databases |
| US6122628A (en) * | 1997-10-31 | 2000-09-19 | International Business Machines Corporation | Multidimensional data clustering and dimension reduction for indexing and searching |
| US6496819B1 (en) * | 1998-12-28 | 2002-12-17 | Oracle Corporation | Rewriting a query in terms of a summary based on functional dependencies and join backs, and based on join derivability |
| US6542904B2 (en) * | 1999-07-30 | 2003-04-01 | International Business Machines Corporation | Method and system for efficiently providing maintenance activity on a relational database that is utilized within a processing system |
| US6725334B2 (en) * | 2000-06-09 | 2004-04-20 | Hewlett-Packard Development Company, L.P. | Method and system for exclusive two-level caching in a chip-multiprocessor |
| AU2001271670A1 (en) * | 2000-06-29 | 2002-01-14 | Alpha Blox Corporation | Caching scheme for multi-dimensional data |
| US6718338B2 (en) * | 2001-06-26 | 2004-04-06 | International Business Machines Corporation | Storing data mining clustering results in a relational database for querying and reporting |
-
2002
- 2002-04-15 US US10/122,502 patent/US7080081B2/en not_active Expired - Lifetime
-
2003
- 2003-04-03 JP JP2003100031A patent/JP3945771B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6192781B1 (ja) * | 2016-07-26 | 2017-09-06 | 三菱電機株式会社 | データ管理プログラム及びデータ管理装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| US7080081B2 (en) | 2006-07-18 |
| US20030195898A1 (en) | 2003-10-16 |
| JP3945771B2 (ja) | 2007-07-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3945771B2 (ja) | データベース・システム | |
| US7765211B2 (en) | System and method for space management of multidimensionally clustered tables | |
| US7469241B2 (en) | Efficient data aggregation operations using hash tables | |
| JP3979846B2 (ja) | リレーショナルデータベース管理システムに多次元データを記憶する方法 | |
| US6505205B1 (en) | Relational database system for storing nodes of a hierarchical index of multi-dimensional data in a first module and metadata regarding the index in a second module | |
| EP1629406B1 (en) | Limiting scans of loosely ordered and/or grouped relations using nearly ordered maps | |
| US6141655A (en) | Method and apparatus for optimizing and structuring data by designing a cube forest data structure for hierarchically split cube forest template | |
| US6374232B1 (en) | Method and mechanism for retrieving values from a database | |
| US6629102B1 (en) | Efficiently updating a key table during outline restructure of a multi-dimensional database | |
| US6470344B1 (en) | Buffering a hierarchical index of multi-dimensional data | |
| US7158996B2 (en) | Method, system, and program for managing database operations with respect to a database table | |
| US20150286681A1 (en) | Techniques for partition pruning based on aggregated zone map information | |
| US6480848B1 (en) | Extension of data definition language (DDL) capabilities for relational databases for applications issuing DML and DDL statements | |
| CA2388515C (en) | System for managing rdbm fragmentations | |
| US20120323971A1 (en) | Optimizing data storage and access of an in-memory database | |
| JPH07129450A (ja) | 区分されたオブジェクトのデータベースの多層索引構造を生成する方法及びシステム | |
| US20230103328A1 (en) | Data compression techniques | |
| US7310719B2 (en) | Memory management tile optimization | |
| US6456998B1 (en) | Efficient processing of parent-child relationships in a relational database management system | |
| US6925463B2 (en) | Method and system for query processing by combining indexes of multilevel granularity or composition | |
| US6453322B1 (en) | Extension of data definition language (DDL) capabilities for relational databases for applications issuing multiple units of work | |
| US6421677B1 (en) | Extension of data definition language (DDL) capabilities for relational databases for applications issuing DDL statements | |
| JPH09305622A (ja) | 文書検索機能を有するデータベース管理方法およびシステム | |
| US20020138464A1 (en) | Method and apparatus to index a historical database for efficient multiattribute SQL queries | |
| CA2427071C (en) | Method and system for space management for multidimensionally clustered tables |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060613 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060830 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20060830 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060830 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070227 |
|
| 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: 20070403 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070404 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070406 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110420 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110420 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |