JP3945771B2 - データベース・システム - Google Patents
データベース・システム Download PDFInfo
- Publication number
- JP3945771B2 JP3945771B2 JP2003100031A JP2003100031A JP3945771B2 JP 3945771 B2 JP3945771 B2 JP 3945771B2 JP 2003100031 A JP2003100031 A JP 2003100031A JP 2003100031 A JP2003100031 A JP 2003100031A JP 3945771 B2 JP3945771 B2 JP 3945771B2
- Authority
- JP
- Japan
- Prior art keywords
- block
- index
- storage device
- processing
- dimension
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/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)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般にデータベース・システムに関し、特にリレーショナル・データベースにおいて多次元ディスク・クラスタリングを実現する手法、ならびにリレーショナル・データベースに格納された情報に対する多次元ディスク・クラスタリングを用いた効率的なアクセス手法および保守手法に関する。（クラスタリング〔クラスタ化〕とは属性が同じものを複数個集めて１つのものにすることである。）
【０００２】
【従来の技術】
収益性を改善するために、ほとんどすべてのビジネス主体がデータウェアハウスを用いてビジネス・インテリジェンスを獲得することに関心を抱いている。技術世界で広く認識されているところによれば、大部分のデータウェアハウスは多次元態様で編成されている。ラルフ・キンボールら著『データウェアハウス・ツールキット：次元データウェアハウスを構築するための実戦手法』（Ralph Kimball, et al., The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehoses, John Wiley & Sons, ISBN: 0471153370, 1996）には、多次元スキーマを用いてデータウェアハウスをモデル化する方法が記載されている。
【０００３】
比較的小規模のデータウェアハウスの構築には相変わらず、多くのＯＬＡＰ（online analytical processing: 多次元分析）システムで多次元配列設計が用いられている。しかし、この多次元配列構造は１００ギガバイトを超える記憶容量を必要とするような大規模データウェアハウス用にうまく拡張することができない。このような大規模データウェアハウスはいまだにリレーショナル・データベース・モデルを用いて実装されている。既存のリレーショナル・データベースも何らかのクラスタ化とデータ区分化を備えているけれども、それらの手法は多次元データをサポートするのには十分でない。
【０００４】
ＯＬＡＰシステムは多くの次元あるいはすべての次元を用いてデータを編成しようとするものである。効率性の観点から、概念的多次元配列は実際には多層構造によって実装されている。次元は各次元値に対して予期されるエントリ数に基づいて密な集合と粗な集合に分けられる。密な次元は多次元配列として実装され、粗な次元は各副配列を指示するのに使われる。アール（Earle)の米国特許第５３５９７２４号にはそのような手法が記載されている。この構成でもまだ非効率である。というのは、密な次元は部分的にしか利用されていないからである。たとえば、研究報告によれば、実世界のデータでは密な配列は通常約２０％しか占有されていない。
【０００５】
空間データベースや地理情報システムでは、２次元あるいは３次元のデータ・モデルを用いている。空間データを編成したり索引付けしたりするデータ構造や方法が数多く提案されている。たとえば、Ｒ−Ｔｒｅｅ、ＱｕａｄＴｒｅｅ、Ｇｒｉｄ Ｆｉｌｅなどである。これらの索引付け構造のうちにはリレーショナル・データベース管理システム（ＲＤＢＭＳ）の拡張として実装されているものもあるが、データウェアハウスなどの実装で必要な保守と照会処理の要件を満たしているとは考えられていない。さらに、これらのシステムでは、２次元あるいは３次元のデータを効率的にクラスタ化する手法は考慮されていない。
【０００６】
【課題を解決するための手段】
リレーショナル・データベース管理システムにおいて、少なくとも１つの次元による表のクラスタリングを保守する効率的なスペース管理手法を開示する。さらに、これらの表とともに使用する効率的な照会処理手法と保守手法も提供する。
【０００７】
本発明の一側面により、リレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法を提供する。この方法は表定義パラメータを用いてリレーショナル・データベースの表の次元を特定するステップを備えている。上記表はデータから成るブロックを用いて各次元にクラスタ化されている。上記表の各次元ごとにブロック索引を作成する。本発明の別の側面によると、ブロックは連続記憶スペースに情報を格納している。本発明の別の側面によると、各ブロック索引はブロックＩＤのリストに関連付けられた少なくとも１つのキーを備えている。本発明の別の側面によると、上記表の次元は上記表の少なくとも１つの列に関連付けられている。本発明の別の側面によると、上記表定義パラメータは表作成ステートメントまたは表変更ステートメントに関連付けられている。本発明の別の側面によると、上記表は多次元表である。本発明の別の側面によると、この多次元表はたとえばデータウェアハウス用の典型的な用途情報をモデル化するのに用いる。しかしながら、認識すべき点を挙げると、上記表は他の様々な目的に用いることができる。
【０００８】
本発明のさらに別の側面によると、上記方法はさらに複合次元索引を作成するステップを備えている。本発明のさらに別の側面によると、上記複合次元索引は自動的に作成する。本発明の一側面によると、上記複合次元索引は複合キーのリストを備えており、各複合キーは多次元表のセルに関連付けられているとともに、当該セル用のブロックＩＤを少なくとも１つ有している。
【０００９】
本発明のさらに別の側面によると、上記方法はさらに上記表用のビット・マップを作成するステップを備えている。上記ビット・マップの各要素は上記表に関連付けられたブロックの現在の状態に関連付けられている。本発明の別の側面によると、各ブロックは状態情報の複製を備えている。本発明の別の側面によると、上記ビット・マップは、たとえば元のビット・マップが破損したり使用できなくなったりしたときに、上記状態情報の複製を用いて作成する。
【００１０】
本発明のさらに別の側面によると、上記方法はさらに上記表に格納されている情報を求める照会を処理するステップを備えている。本発明のさらに別の側面によると、照会を処理するステップはさらに、個々のブロック索引または複合索引の情報を用いてブロックＩＤのリストを取得するステップと、上記表のブロックをスキャンしてレコードを探し出すステップとを備えている。本発明の別の側面によると、照会を処理するステップは、上記表全体をスキャンするステップと、レコード基準索引を用いてレコードを探し出すステップとを備えている。本発明の別の側面によると、上記方法はさらに索引ＡＮＤを行なうステップを備えている。本発明の別の側面によると、上記方法はさらに索引ＯＲを行なうステップを備えている。本発明の別の側面によると、上記方法はコスト・モデルに基づいて照会計画を作成するステップを備えている。
【００１１】
本発明のさらに別の側面によると、上記方法はさらに保守要求を処理するステップを備えている。本発明の別の側面によると、この保守要求にはロード、データベースの再編成、レコードの挿入、レコードの削除、パージ、および更新がある。本発明の別の側面によると、上記保守操作を実行したあとであってもクラスタリングは維持される。
【００１２】
本発明のさらに別の側面によると、ロード操作または挿入操作は、上記表に関連付けられたブロックを１つ使用するステップ、または、（空〔から〕のスペースがない場合に）新たなブロックを割り当てるステップを備えている。本発明の別の側面によると、保守操作が再編成、削除、またはパージである場合にはスペースを再利用する。
【００１３】
本発明のこれらの側面および他の側面、特徴、ならびに利点は、次に示す添付図面とともに読まれるべき好適な実施形態の詳細な説明によって明らかになる。
【００１４】
【発明の実施の形態】
まず、リレーショナル・データベース管理システム（ＲＤＢＭＳ）を用いた、本発明に係る多次元ディスク・クラスタリング用の環境を図１の文脈で説明する。システム１００はメモリ１０１に接続されたプロセッサ１０２、少なくとも１つの入出力（Ｉ／Ｏ）装置１０４、およびＲＤＢＭＳ１０３を備えている。プロセッサ１０２は本発明に係る方法を実装しうるという点を認識すべきである。あるいは、ＲＤＢＭＳ１０３が自分用のプロセッサ、メモリ、およびＩ／Ｏ装置から成る構成（図示せず）を備えて本発明に係る方法を実装してもよい。この構成では、たとえばサーバ・プラットフォームにＲＤＢＭＳ１０３を常駐させ、プロセッサ１０２、メモリ１０１、およびＩ／Ｏ装置１０４をクライアント・システム中のプロセッサ１０２に付随させてもよい。無論、当業者が容易に認識しうるように、本発明の本旨と範囲のうちでＲＤＢＭＳ１０３を用いて照会を処理しうるように適合した構成は他にも数多くある。
【００１５】
メモリ１０１はたとえばプロセッサ１０２が自分が使用した情報を格納する際に使用する。Ｉ／Ｏ装置１０４にはキーボード、マウス、および／または、ユーザが照会および／または他のデータをシステム１００に入力するのを可能にする他の任意のデータ入力装置がある。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）Ｉ／Ｏ装置１０４にはディスプレイ、プリンタ、および／または、照会に付随する結果および／または他のプロセッサ動作をユーザが閲覧（観察）するのを可能にする他の任意の出力装置がある。ＲＤＢＭＳ１０３はＳＱＬ（構造化照会言語）コマンド（あるいは他の種類の照会）を処理するシステム・ソフトウェア（たとえば図２に示すようにもの）を備えている。上記処理には、たとえばＳＱＬコマンド（あるいは他の種類の照会）を最適化すること、それらを実行してプロセッサ１０２に戻された情報を取得することなどがある。理解すべき点を挙げると、ＲＤＢＭＳ１０３に付随する構造化データは複数の行と列を備えた個々の表中に編成されている。次に動作を説明する。普通の構成では、Ｉ／Ｏ装置１０４として標準のコンピュータ・キーボードおよび／またはポインティング・デバイスなどを使用しているエンドユーザが特定のＳＱＬコマンドを入力する（あるいは特定のＳＱＬコマンドを生成させる）。次いで、プロセッサ１０２がＩ／Ｏ装置１０４からこのコマンドを受け取ったのち、それをＲＤＢＭＳ１０３に送る。次いで、ＲＤＢＭＳ１０３は上記ＳＱＬコマンドを解析し、解析結果を最適化し、それをＲＤＢＭＳ自身が内蔵している情報に対して実行する。次いで、ＲＤＢＭＳ１０３は結果表をプロセッサ１０２に送り返す。プロセッサ１０２は当該結果表をＩ／Ｏ装置１０４を使用しているエンドユーザに表示する。しかしながら認識すべき点を挙げると、ＲＤＢＭＳ１０３と対話する方法はこれ以外にも多数ある。たとえば、バッチ・モードで実行しているコンピュータ・プログラムは、ユーザの直接的な対話を必要とせずにＲＤＢＭＳ１０３と対話することができる。
【００１６】
認識すべき点を挙げると、ここで使用している用語「プロセッサ」はたとえばＣＰＵ（中央処理装置）を含む任意の処理装置を含むことを意図している。ここで使用している用語「メモリ」はプロセッサすなわちＣＰＵに付随するメモリ、たとえばＲＡＭ、ＲＯＭ、固定記憶装置（たとえばハード・ディスク駆動装置）、着脱可能記憶装置（たとえばディスケット）などを含むことを意図している。さらに、ここで使用している用語「入出力装置」すなわち「Ｉ／Ｏ装置」は、たとえば照会を作成するおよび／または処理装置にデータを入力する少なくとも１つの入力装置（たとえばキーボード）、および／または、照会結果および／または処理装置に付随する他の結果を提示する少なくとも１つの出力装置（たとえばＣＲＴディスプレイおよび／またはプリンタ）を含むことを意図している。あるプロセッサに付随する様々な構成要素は他のプロセッサが共用することができる、という点も理解すべきである。以上のとおりであるから、ここで説明する本発明の手法を実行する命令すなわちコードを含むソフトウェア・コンポーネントは、プロセッサに付随する少なくとも１つの記憶装置（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置など）に格納しておき、使用しうる状態になったら一部または全部を（たとえばＲＡＭ）にロードし、ＣＰＵが実行する。
【００１７】
図１に示す典型的な環境は本発明を限定することを意図していない、ということは当業者が容易に理解しうる点である。本発明の本旨と範囲の内で他の代替可能な環境を用いることもできる、ということも当業者が容易に認識しうる点である。
【００１８】
図２は典型的なＲＤＢＭＳ１０３を示す図である。ＲＤＢＭＳ１０３は照会コンパイラ２０１、コード・ジェネレータ２０２、実行エンジン２０３、アクセス・メソッド・エンジン２０４、バッファ・マネージャ２０５、ユーティリティ・エンジン２０６、データ・マネージャ２０７、および残余コンポーネント２０８を備えている。
【００１９】
本発明の好適な実施形態では、ＲＤＢＭＳ１０３としては、インターナショナル・ビジネス・マシーンズ・コーポレーションがＵＮＩＸ（Ｒ）、ＷＩＮＤＯＷＳ（Ｒ） ＮＴその他のシステム用に提供しているＤＢ２製品を用いることができる。しかしながら、認識すべき点を挙げると、本発明はＤＢ２製品であれ他の製品であれそれに付随する任意のリレーショナル・データベース・ソフトウェアに適用することができる。
【００２０】
動作中、ＲＤＢＭＳ１０３はたとえばコンピュータ・システムで実行され、ネットワーク・インタフェースを用いて少なくとも１つのクライアントと通信する。ＲＤＢＭＳ１０３はユーザからコマンドを介して命令を受け取ることにより、スタンドアロン・サーバ・モードで動作することもできる。通常、クライアント／ユーザがＲＤＢＭＳ１０３が処理するＳＱＬコマンドを発行すると、結果が返される。動作中、照会コンパイラ２０１は入力ＳＱＬコマンドを解析したのち、コード・ジェネレータ２０２を使って実行計画を作成する。解析したＳＱＬコマンドは通常、内部表現に変換したのち、最適化する。最適化には正しい結果を得るために代替可能なストラテジー（戦略）をいくつか参照するステップと、最も効率的なストラテジーを選択するステップとが含まれる。実行エンジン２０３は実行計画を解釈・実行して所望の結果を生成する。その際、実行エンジン２０３はデータ・マネージャ２０７に要求を出して表から情報を取得する。これは利用可能な索引を使い、表群をスキャンし、など、照会コンパイラ２１０（または別個の最適化プログラム）が決めた方法で行なう。実行エンジン２０３はアクセス・メソッド・エンジン２０４を使い、当該アクセス・メソッド・エンジン２０４（または外部）に格納されている基礎データベース表群に効率的にアクセスする。次いで、関連するデータ項目を取得してバッファ・マネージャ２０５に格納し当該データの再利用に備える。通常、リレーショナル・データベース管理システムは順次表スキャン方式に加え、索引基準表アクセス方式を備えている。ＲＤＢＭＳシステムでは、Ｂツリー索引が最も好適な索引手法である。また、ＲＤＢＭＳシステムのなかには、少なくとも１つの列（または索引）を用いて基礎データをクラスタ化すること、および／または区分することができるものもある。
【００２１】
本発明によると、ここで説明する多次元クラスタリング手法は次に示すＲＤＢＭＳ１０３の主要コンポーネントに影響を及ぼす。
【００２２】
（１）データ・マネージャ２０７とアクセス・メソッド・エンジン２０４：データにアクセスするために、Ｂツリー索引手法を変更するのに加え、新たなデータ設計とレコード管理構造をいくつか提供する。また、コンカレント・アクセスとデータ構造の復旧とを管理する手法を新たにサポートする。
【００２３】
（２）実行エンジン２０３：データ・マネージャ２０７とアクセス・メソッド・エンジン２０４に生じた変化を利用する、照会処理用の演算子とデータベース保守操作とを新たに提供する。
【００２４】
（３）照会コンパイラ２０１とコード・ジェネレータ２０２：新たな演算子と既存の演算子との間で選択を行なうコスト基準の新たな手法を提供する。
【００２５】
（４）ユーティリティ・エンジン２０６：ユーティリティ操作を実行する新たな方式、たとえばバルク（大量）ロードやデータ認識などを提供する。
【００２６】
一般に、ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群は、コンピュータ読み取り可能な媒体すなわちコンピュータによって読み取ることのできる媒体に有形的に記録することができる。ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群はすべて、コンピュータ・システムによって読み取られて実行されると、本発明を実装および／または使用するのに必要なステップを当該コンピュータ・システムに実行させる命令群から構成されている。ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群は、オペレーティング・システムの制御の下で、適切なデータ記憶装置から実動中に使用される、コンピュータ・システムのメモリにロードする。
【００２７】
図３は２次元にクラスタ化された典型的な多次元表を示す図である。図３に示す多次元表は「年月（YearAndMonth）」３００なる次元と「州（Province）」３１０なる次元にクラスタ化されている。多次元表中のレコードはブロック群に格納されている。各ブロックはディスクその他好適な媒体に格納された連続ページから成るある分量のエクステントを保有している。（エクステントとは記憶媒体上で１つのデータ・セットが占める領域のことである。）図３では、ブロックは長円で表されており、多次元表に割り当てられたエクステント群の論理順序に従って番号が付されている。たとえば、長円３０１は多次元表中の１番目のブロックすなわちブロック１を指示している。図３中の格子はこれらのブロックの論理区分化を表わしている。各正方形（たとえば正方形３０２）は論理セルを表わしている。格子中の行または列は特定の次元に対するスライスを表わしている。（スライスとはある事象から切り出された薄片のことである。）たとえば、州３１０列中の値「ＯＮ」（「オンタリオ（Ontario)」の略）を含むレコードはすべて、格子中の「ＯＮ」列によって画定されたスライスに含まれるブロック群に存在する。実際、このスライス中の各ブロックは州フィールドが「ＯＮ」であるレコードしか含んでいない。したがって、格子中のこのスライスすなわちこの列に、あるブロックが含まれるのは、州フィールドが「ＯＮ」であるレコードを当該ブロックが含んでいる場合だけである。図３に示す典型的な多次元表では、「ＯＮ」州列に対するスライスにはブロック９、１６、１８、１９、２２、２４、２５、３０、３６、３９、４１、４２が含まれている。
【００２８】
ここに示す典型的な表ではブロック１から開始する順番でブロック群に番号を付したけれども、他の多くの方法でブロック群を特定しうるということを認識すべきである。たとえば、表中の１番目のブロックはブロック０と名付けることもできる。また当業者が認識しうるように、本発明の本旨と範囲の内で、表に関係する情報の部分を特定する他の様々な方法を案出することができるとともに、異なる用語法を用いることもできる。
【００２９】
図４は図３の典型的な多次元表の各次元に次元ブロック索引を備えた図である。あるスライスを構成しているのはどのブロックであるか、すなわち特定の次元キー値を有するレコードをすべて含むのはどのブロックであるかを判断するのを容易にするために、表を生成するときに各次元ごとに次元ブロック索引を自動的に生成する。したがって、年月次元３００には次元ブロック索引４００を生成し、州次元３１０には次元ブロック索引４１０を生成する。各次元ブロック索引は既存のレコード基準索引と同じ方法で構築することができる。ただし、リーフ（葉）のレベルでは、キーはレコードＩＤ（ＲＩＤ）ではなくブロックＩＤ（ＢＩＤ）を指示している。都合のよいことに、各ブロックはレコード群から成る多数のページを潜在的に含んでいるから、これらのブロック索引はＲＩＤ索引よりもはるかに小さい。また、これらのブロック索引は新たなブロックが必要になりそれをセルに付加するとき、またはセルから除去しうるように既存のブロックを空（から）にするときに更新するだけでよい。
【００３０】
スライス（すなわちある次元における特定のキー値を有するレコードをすべて備えたページ群を含むブロック群の集合）は、関連する次元ブロック索引中に当該キー値に対するＢＩＤリストによって表わすことができる。
【００３１】
図４に示す典型的な多次元表において、州次元が「ＯＮ」であるレコードをすべて含むスライスを探すには、州次元ブロック索引でこのキー値を調べる。すると、次に示すキーが見つかる。
＜ＯＮ：９、１６、１８、１９、２２、２４、２５、３０、３６、３９、４１、４２＞
ただし、キーは＜キー値：ＢＩＤ＞対という形をしている。
【００３２】
上記キーはキー値（すなわち「ＯＮ」）とＢＩＤのリストから構成されている。各ＢＩＤはブロックの場所を含んでいる。この例では、列挙されているブロック番号は多次元表の格子中にある「ＯＮ」列（すなわちスライス）中にあるものと同じであることが分かる。同様に、年月次元が「９９０２」であるレコードをすべて含むブロックのリストを探すには、年月次元索引でこのキー値を調べると、次に示すキーが見つかる。
＜９９０２：２、５、７、８、１４、１５、１７、１８、３１、３２、３３、４３＞
【００３３】
多次元表のクラスタリングはＳＱＬ言語で特定することができる。それには、Ｃｒｅａｔｅ Ｔａｂｌｅ（表作成）ステートメントまたはＡｌｔｅｒ Ｔａｂｌｅ（表変更）ステートメントに付加する文節に、クラスタリング属性を特定しうる適切なものを使用する。たとえば、次に示すＣｒｅａｔｅ Ｔａｂｌｅステートメントを用いてこの例の表を作成することができる。
CREATE TABLE TABLE＿1 (Date DATE, Province CHAR(2),
YearAndMonth INTEGER
DIMENSIONS (YearAndMonth, Province);
【００３４】
この場合、年月（YearAndMonth）次元と州（Province）次元はTABLE ＿1 用にDIMENSIONS文節を用いて定義されている。多次元表のクラスタリングは当該多次元表中のすべてのデータに適用されなければならない。特に、既存の表にＡｌｔｅｒ Ｔａｂｌｅコマンドを用いてクラスタリングを特定する場合には、データの再編成も実行する必要がある。留意点を挙げると、クラスタリング属性用のブロック索引は自動的に作成することができる。
【００３５】
図５は典型的な複合次元索引用のデータ構造を示す図である。レコードを表に挿入するとき、その次元値用のセルが既に存在するかどうか知る必要がある。上記セルが存在する場合、可能なら当該レコードを上記セルの既存のブロックに挿入し、既存のブロックが満杯なら上記セルに別のブロックを付加する。上記セルが存在しない場合には、新たなセルを作成しそれにブロックを付加する必要がある。これを自動的な保守操作とするには、複合次元索引と呼ばれ多次元表を作成するときに作成しうるブロック索引を新たに用いて実装することができる。この複合次元索引は多次元表中のすべての次元列について作成するから、各キー値は表中の特定のセルに対応し、そのＢＩＤリストは当該セルを構成するブロックから成る。これを図５に示す。この複合ブロック索引によって、次元用の値の特定の集合を有するブロックを迅速かつ効率的に検索するのが容易になる。複合ブロック索引は挿入操作中に、対象とする多次元表の次元群によるデータの物理的クラスタリングを動的に管理・保守するのにも使うことができる。認識すべき点を挙げると、Ｒツリーなどの多次元索引構造も、それらがレコードまたはオブジェクトではなくブロックを指示している場合には、複合次元索引を実装するのに使用することができる。
【００３６】
図６は図４の多次元表に新たな次元を備えて拡張したものを示す図である。いま、図６に示すように、年月次元３００、州次元３１０、および色（Color)次元６００から成る次元を備えた多次元表を考える。この多次元表は論理立方体と考えることができる。この例では、４つのブロック索引を作成することになる。すなわち、個々の次元（すなわち年月次元３００、州次元３１０、および色次元６００）ごとに１つずつのブロック索引と、キーとしてこれらの次元のすべてを備えた複合次元索引（図示せず）とである。
【００３７】
本発明の目標の１つは効率的な照会処理を容易にすることである。以下、本発明によって容易になる照会処理方法を説明する。年月次元３００、州次元３１０、および色次元６００から成る次元を備えた、図６に示す３次元立方体を考える。たとえば「すべての日付と地域にわたって「色が『赤』である」合計売上高はいくらか」のような照会は、いくつかの異なる方法で処理することができる。この照会を処理する方法には、次に示す選択肢がある。
（１）表スキャン：表全体をスキャンして「色が『赤』である」行だけを選択する。
（２）ブロック・スキャン：色に関するブロック索引を使って検索範囲をブロックの特定の集合に狭める。
（３）レコード・スキャン：（存在する場合には）色に関するレコード基準索引を使って検索範囲をレコードの特定の集合に狭める。
【００３８】
照会最適化プログラムでコスト・モデルを用いることにより、これらの選択肢のうちから最良のものを見つけ出すことができる。ブロック・スキャン方法は本発明で導入された新しい操作である。このブロック・スキャンは次に示す２つのステップで実行する。
(i) ブロック索引をスキャンして照会述語を満たすブロックＩＤを見つけ出す。
(ii)当該ブロック中のレコードをすべて処理する。
これは余分な述語を含んでいてもよい。ブロック・スキャン操作が最も効率的なのは、所定の照会に対して１つのブロック、ブロックの集合、またはレコードの集合の大部分を処理する必要がある場合である。このような要件はデータウェアハウスではきわめて普通のことである。たとえば、上述した照会はブロックの全体集合へのアクセスを含むものと考えられる。したがって、この照会を処理する方法としては、ブロック・スキャン操作が最も効率的な方法になると考えられる。
【００３９】
留意点を挙げると、多次元表に対してＲＩＤ索引もサポートすれば、索引ＡＮＤ手法および索引ＯＲ手法によってＲＩＤ索引とブロック索引とを組み合わせることができる。あるいは、多次元表を既存の任意の表と同様に処理することもできる。たとえば、多次元表に対してトリガー、参照保全性、ビュー、および自動サマリー表を定義することができる。
【００４０】
図７（ａ）（ｂ）（ｃ）はブロック索引を用いて索引ＡＮＤを実行する方法を示す図である。いま、図６に示す３次元立方体に対する「色が『青』であり、かつ（ＡＮＤ）、州が『ＱＢ』である」という照会を考える。まず、「色が『青』である」ブロックをすべて含むスライスを求める。それには、多次元表に付随する色次元ブロック索引で「青」キー値を探す。その結果、次に示すキーが見つかる。
＜青：１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４＞
これは図７（ａ）の立体図に示す（灰色で強調表示した）スライス７１５に対応している。
【００４１】
次いで、「州が『ＱＢ』である」レコードをすべて含むブロックを求める。それには、州次元ブロック索引で「ＱＢ」キー値を探す。その結果、次に示すキーが見つかる。
＜ＱＢ：１１、１２、１３、１４、２７、２８、３５、３７、４０、５１＞
これは図７（ｂ）の立体図に示すスライス７２５に対応している。上記２つのキー値を有するレコードをすべて含むブロックの集合を探すには、上記２つのスライスの交差部を見つける必要がある。これを行なうには、上記２つのＢＩＤリストの索引ＡＮＤをとる。この例では、共通ＢＩＤ値は「１１、１２、１３、１４」である。これは図７（ｃ）に示す立体図の区画７３５に対応している。
【００４２】
スキャンすべきブロックのリストが得られたら、各ブロックに対してミニ・リレーショナル・スキャンを実行するだけでよい。この操作には入出力（Ｉ／Ｏ）が１回しかない（したがって高速に行なうことができる）。なぜなら、１つのブロックはディスクに１つのエクステントとして格納され、１つの単位としてバッファプールに読み取ることができるからである。また、照会述語を再適用する必要があり、かつ、一部の述語が次元値にしか存在しない場合には、それらの述語をブロック中の１つのレコードに再適用するだけでよい。なぜなら、ブロック中のすべてのレコードに同じ次元キー値が存在することが保証されているからである。また、他に述語があっても、それらがブロック中の残りのレコードに存在するかどうか検査するだけでよい。
【００４３】
ブロック基準索引ＡＮＤ方式はビット・マップ方式を用いることができるから、きわめて効率的である。また、ブロック・レベル索引はＲＩＤ索引よりも小さいから、索引ＡＮＤに要する処理時間はきわめて少ない。最後に、ブロックの交差リストはブロック基準Ｉ／Ｏ操作を使って効率的にアクセスすることができる。全体として、ここで説明した操作はきわめて効率的であり、この手法以前の既存のものよりもはるかに高速である。
【００４４】
多次元表用に既存のＲＩＤ基準索引もサポートすれば、索引ＡＮＤ操作と索引ＯＲ操作によってＲＩＤ索引とブロック索引とを組み合わせることができる。
【００４５】
上述したように、ブロック索引を用いてブロック基準索引ＯＲ操作も実行することができる。たとえば、照会が「州が『ＯＮ』であるか、または（ＯＲ）、州が『ＢＣ』である」という条件を含んでいる場合、州ブロック索引をカテゴリごとにスキャンしたのち、ＯＲ操作を実行するとブロックの合計リストが得られる。また、このＯＲ操作によれば、たとえば「州が『ＡＢ』であるか、または（ＯＲ）、色が『赤』である」といった条件の場合に生じる可能性のあるＢＩＤの重複を除去することができる。
【００４６】
副ブロック索引スキャンもサポートすることができる。副ブロック索引があると、単一のＢＩＤが多数のキーの下に存在しうることになる。このことはＲＩＤ索引では決してありえない、ということに留意する必要がある。副ブロック索引を用いてファクト表にアクセスする際に重要なのは、適格ブロックのスキャンが１回しかないという点である。すなわち、その１回のスキャンで適格ブロックのすべてのレコードにアクセスする必要があり、当該ブロックを再度フェッチしてはならない。この結果、重複を除去しうるようにブロックの適格リストを保守することが必要になる。
【００４７】
図８は多次元表に付随する典型的なブロック・マップを示す図である。ブロック・マップには、特定の多次元表に属す各ブロックの現在の状態が記録されている。たとえば、このブロック・マップ中の要素８０１は多次元表のブロック０を表わしている。その使用可能状態は「Ｘ」であり、予約済みであることを表わしている。したがって、ブロック０は多次元表のデータ行を格納するのにまったく使用できない。ブロック・マップ中の要素８０２はブロック８を表わしている。その使用可能状態は「Ｕ」であり、使用中であることを表わしている。同様に、ブロック１〜７、１０〜１５、１７、２０、２５、２６も使用中である。このことは多次元表中のレコードはこれらのブロック中に存在するということを意味している。ブロック・マップ中の要素８０３はブロック１９を表わしている。その使用可能状態は「Ｆ」であり、空（から）であることを表わしている。同様に、ブロック２１、２３、２４、２７〜２９も空である。このことはこれらのブロックが現在、多次元表によって使用されておらず、使用可能であることを意味している。ブロック・マップ中の要素８０４はブロック２２を表している。その使用可能状態は「Ｌ」であり、当該ブロックは最近に情報がロードされたことを表わしている。同様に、ブロック９、１６、３０〜３３も最近にロードされたブロックである。ブロック・マップ中の要素８０６はブロック１８を表わしている。その使用可能状態は「Ｃ」である。ブロック１８は以前にロードされたものであるが、依然として制約検査を行なう必要がある。
【００４８】
認識すべき点を挙げると、図８に示すブロック・マップは特定の値を有する様々な状態フラグを備えているけれども、他の値を用いて異なるブロック状態または新たなブロック状態を反映させることもできる。さらに認識すべき点を挙げると、新たなブロックその他の情報を表わす新たな要素を動的に割り当てうるような方法で、ビット・マップのデータ構造を構築することもできる。
【００４９】
各ブロックは当該ブロックの第１ページの第１スロットに配置されたヘッダを備えている。ヘッダには（他の様々な事項とともに）ブロック状態のコピーとビット・マップとが格納されている。ブロック状態のコピーが格納されている結果、ブロック・マップが削除されたり破損されたりした場合、必要なら当該ブロック・マップを再作成することができる。上記ビット・マップはブロックの全ページをカバーし空のページを指示するものである（たとえば０＝空、１＝非空、オーバーフロー・レコードまたはポインタ・レコードしか備えていない場合であってもこのようにする）。また、各ブロックはそれに付随するフリー・スペース・コントロール・レコード（ＦＳＣＲ）を備えている。ＦＳＣＲにはページ・オフセットとページ当たりのフリー・スペースの近似値とが格納されている。これらのＦＳＣＲはたとえば、ブロックの第１ページに位置し、当該ページの第２レコードとして格納される。
【００５０】
上述した表編成はきわめてスペース効率が良い。重要なのは、各セルが少なくとも１ブロック分のデータを有するように多次元キーおよび対応するブロック・サイズを選ぶことである。というのは、最終ブロックのみが部分的に満杯になることが多いからである。この高効率状態は挿入操作、削除操作、またはバックグラウンドでの再編成が頻繁に行なわれる場合であっても維持することができる。これに対して、ＯＬＡＰ編成では上述したように、大量の未使用スペースが生じる。
【００５１】
図９は本発明の手法に従って実行しうる様々な保守機能を示す図である。図９には保守機能９００がある。保守機能９００には、ロード機能９０１、再編成機能９０２、挿入機能９０３、削除機能９０４、パージ機能９０５、および更新機能９０６がある。以下、これらの機能を詳細に説明する。
【００５２】
〔ロード機能９０１〕
通常、比較的大量のデータを表中にロードするには、挿入コマンドを多数個発行する代わりにロード機能を使用する。ロード・ユーティリティを用いれば、特定の方式でフォーマットしたデータ・セットにアクセスし、当該データ・セット中の情報を使って特定の表に行を作成することができる。
【００５３】
重要な点を挙げると、ロード・ユーティリティは効率的な方式を用いてデータを表中に挿入する。多次元表中にデータを首尾よくロードするには、入力を次元値とともに編成することである。（このことは多次元表では初期設定として確立されている。）このことが必要なのは、レコードが次元値とブロック境界によって適切にクラスタ化されていることを保証するためである。たとえば、＜年月＝９９０３、州＝「ＯＮ」、色＝「赤」＞に対応する論理セルに対して１つのビン（大箱）を作成することができる。そうすると、次元属性に関し同じ値を有するレコードはすべてこのビンに割り当てることができる。物理的には、各ビンはデータ・ページ群から成る１つのブロックによって表わすことができる。最近に処理されたビンはメモリ中に保持しておき、それらが満杯になったとき、または他のビンをメモリに持ってくる必要が生じたときにディスクに書き出す。
【００５４】
処理を減らす方法の１つは、ユーザがＬＯＡＤコマンド中で文節を指定できるようにすることである。ユーザ指定の文節として、たとえば
ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ（取り込み順に変更）文節
を挙げることができる。
この任意実行文節（または同じ効果を有する同様の文節）は、入力データ・セットは既に格納順であるから処理をより効率的に行なえるということをロード・ユーティリティに知らせるのに使うことができる。これが役に立つ場合がいくつかある。たとえばデータが次元とキー値によって格納済みの場合である。この場合、ロード・ユーティリティは順番を検証するだけでよい。別の例として、特定のセル用のレコード群をロードする場合に有益である。なぜなら、特定のセルに付加するレコード群の次元値はすべて同じだからである。これが当てはまる例として、表が単一の次元から成り、当該次元の特定値を有するレコード群（たとえば２００１年２月以降の全レコード）にユーザが大童（おおわらわ）になっている場合が挙げられる。このような場合、ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ文節（またはこれと同じ効果を有する同様の文節）を指定すると、ロード・ユーティリティはデータが適切に順序付けられていることを検証するだけでよい。順番が前後したレコードを発見した場合には、ロード・ユーティリティは処理を停止し、たとえば当該表をロード保留状態に置いておけばよい。
【００５５】
〔再編成機能９０２〕
再編成ユーティリティはデータベースにおけるデータの物理的な配置を再編成するのに使用する。データベースの再編成が必要になるのは、フラグメント（断片）化したデータ・スペースをデフラグするため、またはクラスタ索引を有するレコード群を再構成（クラスタ化）するためである。
【００５６】
多次元表の再編成はクラスタリング索引を有する表の場合よりもずっと単純であり、必要になる頻度もずっと低い。多次元表ではクラスタリングを自動的かつ連続的に継続することができるから、データを再クラスタ化するのにもはや再編成を必要としない。しかし、多次元表中のスペースを再利用する（具体的にはセル内のスペースを再利用する）、あるいはオーバーフローしたレコードを除去するのに、再編成ユーティリティを使うことができる。多次元表用の再編成ユーティリティはブロック指向である。複合次元ブロック索引を使うことにより、特定ブロック群中のレコード群にアクセスすることができる。それらのレコード群は再編成パラメータ（たとえば必要な空きスペースの量）を用いてを新たなブロック１つに再構成することができる。この結果、初期論理セルが多数のブロックを含んでいても、再構成後のセルはより少ない数のブロックしか含んでいない、ということが起こりうる。たとえば、あるセルが初めにブロック１、１０、３０、４５を含んでいたとする。この場合、再編成後に当該セルが新たなブロック１、２しか含んでいない、ということがありうる。残りのスペースは他のセルが使用しうるように解放された、あるいはこの表から完全に除去された。また、再編成の終わりには新たなブロック・マップの再構築も行なう。
【００５７】
〔挿入機能９０３〕
挿入には表に新たなレコードを作成することが含まれる。挿入操作中、クラスタリングを維持する必要がある。いま、次元値＜９９０３，‘ＡＢ’＞を有するレコードを（図４に示すような）多次元表中に挿入することを考える。まず、複合ブロック索引を使ってこの新たなレコード用に適切なブロックを特定する必要がある。それには、（図５に示すような）複合ブロック索引でキー値「９９０３，ＡＢ」を探す。その結果、次に示すキーが見つかる。
＜９９０３，ＡＢ：３，１０＞
この場合、キー値「９９０３，ＡＢ」を有するブロックはブロック３とブロック１０の２つあることが分かる。これらのブロックは指定した次元を有するレコードをすべて含んでいるが、それら以外のレコードは含んでいない。したがって、これらのブロックのページのいずれかにスペースがある場合、これらのブロックのうちの１つに新たなレコードを挿入する。これらのブロックのページのいずれにもスペースがない場合には、多次元表に新たなブロックを割り当てるか、多次元表中の以前に空にしたブロックを使用する。その際、（図８に示すような）ブロック・マップを探索して空のブロックを見つけることができる。たとえば多次元表用のビット・マップを調べたら、ブロック４８が現在、多次元表によって使用されていない（すなわちその状態が空を示す「Ｆ」である）ことが分かったとする。この場合、上記新たなレコードをブロック４８のページに挿入する。そして、このブロック４８を、そのＢＩＤを複合ブロック索引に付加することによりセルに割り当てるとともに、各次元ブロック索引に割り当てる。
【００５８】
結果として得られる次元ブロック索引中のキーは次に示すようになる。
＜９９０３：３，４，１０，１６，２０，２２，２６，３０，３６，４８＞
＜ＡＢ：１，３，５，６，７，８，１０，１２，１４，３２，４８＞
結果として得られる複合ブロック索引中のキーは次に示すようになる。
＜９９０３，ＡＢ：３，１０，４８＞
【００５９】
いま、多次元表中に空のブロックがないとする。この場合には、多次元表に新たなブロックを割り当て、行（すなわちレコード）を挿入するのに使う。この場合にも、上述したようにして索引群を更新する。
【００６０】
新たな次元を有するレコードを挿入する場合には、新たなブロックまたは空のブロックを割り当てなければならない。そして、次元ブロック索引と複合ブロック索引に新たなキー値を付加する。
【００６１】
挿入機能を実行する際には、第１レコードをブロックに挿入するときに特に注意するのに加え、第１レコードをブロック中の新たなページに挿入するときにも特別の注意を払う必要がある。それには、各ブロック用のページ・ビット・マップを使ってブロック中のページの状態を保守する。そして、ページに第１レコードが挿入されたら、ページ・ビット・マップ中のビットをセットする。このページ・ビット・マップによって、ブロック中のページの占有状態を追跡することが可能になるとともに、挿入操作や削除操作の際にブロックの状態を保守することが可能になる。
【００６２】
〔削除機能９０４〕
通常の表の削除操作では表中の少なくとも１つのレコードを削除し、削除したレコードが占有していたスペースを解放する。多次元表の削除でも同じことを行なう。しかしながら、ブロック中のページの状態に加え、ブロック全体にも特に注意する必要がある。ページの最終レコードを削除する場合には、ページ・ビット・マップを更新し削除した特定のページに付随するビットをクリア（消去）する。ブロック中のページがすべて空の場合には、このページ・ビット・マップを完全にクリアする。このことは当該ブロックをブロック・マップ中で空とマーク付けしうることを示している。この空のブロックは、たとえば将来の挿入操作やロード操作によって再利用しうる。あるブロックを空にしたら、次元索引もすべて更新し、当該空にしたブロックに付随するＢＩＤを当該ブロックの次元属性に対応する特定のキーから除去する。
【００６３】
〔パージ機能９０５〕
パージとは、関係するレコードから成る大集合を削除するときに使用する特別な形の削除操作である。いま、次に示すＳＱＬステートメントを考える。
Delete from Table ＿1 where color='Red'
色（color)属性は（図６に示す多次元表の場合のように）この多次元表（Table ＿1)の１つの次元であると仮定する。したがって、「色が『赤』である」（color='Red')という制約は「赤」（Red)値に付随するブロックをすべて削除すべきことを示している。これを実行するには、色の次元ブロック索引で「赤」を検索し、付随するＢＩＤのリストを見つけ出せばよい。このリストが「１２、１７、２１、３０」であると仮定する。この多次元表（Table ＿1)にこの他に索引や関係するデータ構造がない場合、これらのブロックを当該多次元表のブロック・マップ中で空とマーク付けしたのち、ブロック索引から上記ＢＩＤを削除することができる。これはきわめて高速の操作であるとともに、ログをとるコストと索引を保守するコストを低減することもできる。
【００６４】
パージ型の削除が適用できることを検出するには、削除ステートメントを検査しその中の制約が少なくとも１つの次元文節に基づいてることを検証すればよい。特に、処理する必要のあるＢＩＤの集合を特定するのに少なくとも１つのブロック索引を用いている場合には、パージ型の削除を使用することを考慮してもよい。最適化プログラムはこれを検出し、それに従った適切な照会計画を作成することができる。留意点を挙げると、最適化プログラムは高速パージを可能にする（または不可能にする）新たな課題にも気づくことになる。これらの課題は当該多次元表に別の索引や制約があるということを意味している。
【００６５】
〔更新機能９０６〕
更新操作には表中の情報を変更することが含まれる。多次元表では、更新には次に示す２種類のものがある。
【００６６】
（１）単純更新：この場合、更新は多次元表中の次元ではない、属性すなわちフィールドにのみ適用される。したがって、行（すなわちレコード）は同じ論理セルに継続して属す。行は変化が生じても新たなスペースが必要とならない限り、同じ場所に存在し続ける。あるいは、行は同じブロック中の新たな場所または別のブロックに移動する可能性もある。このレコード（すなわち行）を移動させたときには、元の場所のＲＩＤはそのままにしておき、オーバーフロー・ポインタ手法を使って新たな場所を指示するようにする。（オーバーフロー・ポインタ手法とは旧レコードが満杯になり新レコードを作ったとき、旧レコードの末尾に新レコードの場所を指示するポインタを格納しておく手法のことである。）新たな場所が新たなブロックである場合には、次元ブロック索引に当該新たなブロックを挿入する必要がある。
【００６７】
（２）次元列の更新：更新が少なくとも１つの次元列に対するものである場合、内部的にはこれを削除と挿入として扱う必要がある。この結果、（更新対象の次元列の）レコードは更新後は新セル中でクラスタ化されているということが保証される。なぜなら、当該レコードは旧セルに属すブロック中には配置できないからである。この操作を実行するには、上述した削除手法と挿入手法とを組み合わせる。
【００６８】
以上、添付図面を参照して本発明の説明目的の実施形態を説明してけれども、理解すべき点を挙げると、本発明はそれら明確な実施形態に限定されず、また、本発明の範囲または本旨の内で当業者は他の様々な変形および変更をなすことができる。
【００６９】
まとめとして以下の事項を開示する。
（１）
リレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法であって、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられている、ステップと
を備えた
方法。
（２）
前記少なくとも１つのブロックの各々が連続記憶スペースから成る、
上記（１）に記載の方法。
（３）
前記少なくとも１つのブロック索引の各々が、少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、
上記（１）に記載の方法。
（４）
前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、
上記（１）に記載の方法。
（５）
前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、
上記（１）に記載の方法。
（６）
前記表が多次元表である、
上記（１）に記載の方法。
（７）
前記多次元表が用途情報を格納するのに使用されている、
上記（６）に記載の方法。
（８）
前記用途情報がデータウェアハウス用のものである、
上記（７）に記載の方法。
（９） さらに、
前記多次元表用の複合次元索引を作成するステップ
を備えた、
上記（６）に記載の方法。
（１０）
前記複合次元索引を作成するステップを自動的に実行する、
上記（９）に記載の方法。
（１１）
前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられているとともに、前記セル用に少なくとも１つのブロックＩＤのリストを備えている、
上記（９）に記載の方法。
（１２） さらに、
前記表用にブロック・マップを作成するステップ
を備え、
前記ブロック・マップの各要素が前記少なくとも１つのブロックの１つ用に状態情報を備えている、
上記（１）に記載の方法。
（１３）
前記少なくとも１つのブロックの各々が状態情報の複製を備えている、
上記（１２）に記載の方法。
（１４）
前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、
前記ブロック・マップを作成する、
上記（１３）に記載の方法。
（１５） さらに、
前記表に格納された情報を求める照会を処理するステップ
を備えた、
上記（１）に記載の方法。
（１６）
前記照会を処理するステップが、
前記少なくとも１つのブロック索引および前記複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップ
を備えた、
上記（１５）に記載の方法。
（１７）
前記照会を処理するステップが、
前記表全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップ
の少なくとも一方を
備えた、
上記（１５）に記載の方法。
（１８）
前記照会を処理するステップが、
索引ＡＮＤ
を備えている、
上記（１５）に記載の方法。
（１９）
前記照会を処理するステップが、
索引ＯＲ
を備えている、
上記（１５）に記載の方法。
（２０）
前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップと
を備えている、
上記（１５）に記載の方法。
（２１） さらに、
保守要求を処理するステップ
を備えた、
上記（１）に記載の方法。
（２２）
前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新
のうちの１つを求める要求から成る、
上記（２１）に記載の方法。
（２３）
前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、
上記（２１）に記載の方法。
（２４）
ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップ
のうちの一方
を備えている、
上記（２２）に記載の方法。
（２５）
再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップ
を備えている、
上記（２１）に記載の方法。
（２６）
機械によって読み取り可能なプログラム記憶装置であって、前記プログラム記憶装置ちはリレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法を実行する、前記機械で実行可能な命令群から成るプログラムが有形的に記録されており、前記方法が、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられている、ステップと
を備えている
プログラム記憶装置。
（２７）
前記少なくとも１つのブロックの各々が連続記憶スペースから成る、
上記（２６）に記載のプログラム記憶装置。
（２８）
前記少なくとも１つのブロック索引の各々が、少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、
上記（２６）に記載のプログラム記憶装置。
（２９）
前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、
上記（２６）に記載のプログラム記憶装置。
（３０）
前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、
上記（２６）に記載のプログラム記憶装置。
（３１）
前記表が多次元表である、
上記（２６）に記載のプログラム記憶装置。
（３２）
前記多次元表が用途情報を格納するのに使用されている、
上記（３１）に記載のプログラム記憶装置。
（３３）
前記用途情報がデータウェアハウス用のものである、
上記（３２）に記載のプログラム記憶装置。
（３４） さらに、
前記多次元表用の複合次元索引を作成するステップ
を備えた、
上記（３１）に記載のプログラム記憶装置。
（３５）
前記複合次元索引を作成するステップを自動的に実行する、
上記（３４）に記載のプログラム記憶装置。
（３６）
前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられているとともに、前記セル用に少なくとも１つのブロックＩＤのリストを備えている、
上記（３４）に記載のプログラム記憶装置。
（３７） さらに、
前記表用にブロック・マップを作成するステップ
を備え、
前記ブロック・マップの各要素が前記少なくとも１つのブロックの１つ用に状態情報を備えている、
上記（２６）に記載のプログラム記憶装置。
（３８）
前記少なくとも１つのブロックの各々が状態情報の複製を備えている、
上記（３７）に記載のプログラム記憶装置。
（３９）
前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、
前記ブロック・マップを作成する、
上記（３８）に記載のプログラム記憶装置。
（４０） さらに、
前記表に格納された情報を求める照会を処理するステップ
を備えた、
上記（２６）に記載のプログラム記憶装置。
（４１）
前記照会を処理するステップが、
前記少なくとも１つのブロック索引および前記複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップ
を備えた、
上記（４０）に記載のプログラム記憶装置。
（４２）
前記照会を処理するステップが、
前記表全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップ
の少なくとも一方を
備えた、
上記（４０）に記載のプログラム記憶装置。
（４３）
前記照会を処理するステップが、
索引ＡＮＤ
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４４）
前記照会を処理するステップが、
索引ＯＲ
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４５）
前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップと
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４６） さらに、
保守要求を処理するステップ
を備えた、
上記（２６）に記載のプログラム記憶装置。
（４７）
前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新
のうちの１つを求める要求から成る、
上記（４６）に記載のプログラム記憶装置。
（４８）
前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、
上記（４６）に記載のプログラム記憶装置。
（４９）
ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップ
のうちの一方
を備えている、
上記（４７）に記載のプログラム記憶装置。
（５０）
再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップ
を備えている、
上記（４６）に記載のプログラム記憶装置。
【図面の簡単な説明】
【図１】 本発明の手法で用いる典型的な環境のブロック図である。
【図２】 本発明に係る典型的なリレーショナル・データベース管理システムの模式図である。
【図３】 本発明の一実施形態に係る２次元にクラスタ化した典型的な多次元表の模式図である。
【図４】 本発明の一実施形態に係り図３の典型的な多次元表に各次元に関する次元索引を備えたものの模式図である。
【図５】 本発明の一実施形態に係る典型的な複合次元索引の模式図である。
【図６】 本発明の一実施形態に係り図３の典型的な多次元表を第３の次元に拡張したものの模式図である。
【図７】 （ａ）〜（ｃ）は本発明の一実施形態に係る索引ＡＮＤ手法の模式図である。
【図８】 本発明の一実施形態に係る典型的なブロック・マップの模式図である。
【図９】 本発明の一実施形態に係る様々な典型的な保守機能の模式図である。
【符号の説明】
１００ システム
１０１ メモリ
１０２ プロセッサ
１０３ ＲＤＢＭＳ
１０４ 入出力（Ｉ／Ｏ）装置
２０１ 照会コンパイラ
２０２ コード・ジェネレータ
２０３ 実行エンジン
２０４ アクセス・メソッド・エンジン
２０５ バッファ・マネージャ
２０６ ユーティリティ・エンジン
２０７ データ・マネージャ
２０８ 残余コンポーネント
３００ 年月次元
３０１ 長円（ブロック）
３０２ 正方形（セル）
３１０ 州次元
４００ 次元ブロック索引
４１０ 次元ブロック索引
６００ 色次元
７１５ スライス
７２５ スライス
７３５ 区画
９００ 保守機能
９０１ ロード機能
９０２ 再編成機能
９０３ 挿入機能
９０４ 削除機能
９０５ パージ機能
９０６ 更新機能
【発明の属する技術分野】
本発明は、一般にデータベース・システムに関し、特にリレーショナル・データベースにおいて多次元ディスク・クラスタリングを実現する手法、ならびにリレーショナル・データベースに格納された情報に対する多次元ディスク・クラスタリングを用いた効率的なアクセス手法および保守手法に関する。（クラスタリング〔クラスタ化〕とは属性が同じものを複数個集めて１つのものにすることである。）
【０００２】
【従来の技術】
収益性を改善するために、ほとんどすべてのビジネス主体がデータウェアハウスを用いてビジネス・インテリジェンスを獲得することに関心を抱いている。技術世界で広く認識されているところによれば、大部分のデータウェアハウスは多次元態様で編成されている。ラルフ・キンボールら著『データウェアハウス・ツールキット：次元データウェアハウスを構築するための実戦手法』（Ralph Kimball, et al., The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehoses, John Wiley & Sons, ISBN: 0471153370, 1996）には、多次元スキーマを用いてデータウェアハウスをモデル化する方法が記載されている。
【０００３】
比較的小規模のデータウェアハウスの構築には相変わらず、多くのＯＬＡＰ（online analytical processing: 多次元分析）システムで多次元配列設計が用いられている。しかし、この多次元配列構造は１００ギガバイトを超える記憶容量を必要とするような大規模データウェアハウス用にうまく拡張することができない。このような大規模データウェアハウスはいまだにリレーショナル・データベース・モデルを用いて実装されている。既存のリレーショナル・データベースも何らかのクラスタ化とデータ区分化を備えているけれども、それらの手法は多次元データをサポートするのには十分でない。
【０００４】
ＯＬＡＰシステムは多くの次元あるいはすべての次元を用いてデータを編成しようとするものである。効率性の観点から、概念的多次元配列は実際には多層構造によって実装されている。次元は各次元値に対して予期されるエントリ数に基づいて密な集合と粗な集合に分けられる。密な次元は多次元配列として実装され、粗な次元は各副配列を指示するのに使われる。アール（Earle)の米国特許第５３５９７２４号にはそのような手法が記載されている。この構成でもまだ非効率である。というのは、密な次元は部分的にしか利用されていないからである。たとえば、研究報告によれば、実世界のデータでは密な配列は通常約２０％しか占有されていない。
【０００５】
空間データベースや地理情報システムでは、２次元あるいは３次元のデータ・モデルを用いている。空間データを編成したり索引付けしたりするデータ構造や方法が数多く提案されている。たとえば、Ｒ−Ｔｒｅｅ、ＱｕａｄＴｒｅｅ、Ｇｒｉｄ Ｆｉｌｅなどである。これらの索引付け構造のうちにはリレーショナル・データベース管理システム（ＲＤＢＭＳ）の拡張として実装されているものもあるが、データウェアハウスなどの実装で必要な保守と照会処理の要件を満たしているとは考えられていない。さらに、これらのシステムでは、２次元あるいは３次元のデータを効率的にクラスタ化する手法は考慮されていない。
【０００６】
【課題を解決するための手段】
リレーショナル・データベース管理システムにおいて、少なくとも１つの次元による表のクラスタリングを保守する効率的なスペース管理手法を開示する。さらに、これらの表とともに使用する効率的な照会処理手法と保守手法も提供する。
【０００７】
本発明の一側面により、リレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法を提供する。この方法は表定義パラメータを用いてリレーショナル・データベースの表の次元を特定するステップを備えている。上記表はデータから成るブロックを用いて各次元にクラスタ化されている。上記表の各次元ごとにブロック索引を作成する。本発明の別の側面によると、ブロックは連続記憶スペースに情報を格納している。本発明の別の側面によると、各ブロック索引はブロックＩＤのリストに関連付けられた少なくとも１つのキーを備えている。本発明の別の側面によると、上記表の次元は上記表の少なくとも１つの列に関連付けられている。本発明の別の側面によると、上記表定義パラメータは表作成ステートメントまたは表変更ステートメントに関連付けられている。本発明の別の側面によると、上記表は多次元表である。本発明の別の側面によると、この多次元表はたとえばデータウェアハウス用の典型的な用途情報をモデル化するのに用いる。しかしながら、認識すべき点を挙げると、上記表は他の様々な目的に用いることができる。
【０００８】
本発明のさらに別の側面によると、上記方法はさらに複合次元索引を作成するステップを備えている。本発明のさらに別の側面によると、上記複合次元索引は自動的に作成する。本発明の一側面によると、上記複合次元索引は複合キーのリストを備えており、各複合キーは多次元表のセルに関連付けられているとともに、当該セル用のブロックＩＤを少なくとも１つ有している。
【０００９】
本発明のさらに別の側面によると、上記方法はさらに上記表用のビット・マップを作成するステップを備えている。上記ビット・マップの各要素は上記表に関連付けられたブロックの現在の状態に関連付けられている。本発明の別の側面によると、各ブロックは状態情報の複製を備えている。本発明の別の側面によると、上記ビット・マップは、たとえば元のビット・マップが破損したり使用できなくなったりしたときに、上記状態情報の複製を用いて作成する。
【００１０】
本発明のさらに別の側面によると、上記方法はさらに上記表に格納されている情報を求める照会を処理するステップを備えている。本発明のさらに別の側面によると、照会を処理するステップはさらに、個々のブロック索引または複合索引の情報を用いてブロックＩＤのリストを取得するステップと、上記表のブロックをスキャンしてレコードを探し出すステップとを備えている。本発明の別の側面によると、照会を処理するステップは、上記表全体をスキャンするステップと、レコード基準索引を用いてレコードを探し出すステップとを備えている。本発明の別の側面によると、上記方法はさらに索引ＡＮＤを行なうステップを備えている。本発明の別の側面によると、上記方法はさらに索引ＯＲを行なうステップを備えている。本発明の別の側面によると、上記方法はコスト・モデルに基づいて照会計画を作成するステップを備えている。
【００１１】
本発明のさらに別の側面によると、上記方法はさらに保守要求を処理するステップを備えている。本発明の別の側面によると、この保守要求にはロード、データベースの再編成、レコードの挿入、レコードの削除、パージ、および更新がある。本発明の別の側面によると、上記保守操作を実行したあとであってもクラスタリングは維持される。
【００１２】
本発明のさらに別の側面によると、ロード操作または挿入操作は、上記表に関連付けられたブロックを１つ使用するステップ、または、（空〔から〕のスペースがない場合に）新たなブロックを割り当てるステップを備えている。本発明の別の側面によると、保守操作が再編成、削除、またはパージである場合にはスペースを再利用する。
【００１３】
本発明のこれらの側面および他の側面、特徴、ならびに利点は、次に示す添付図面とともに読まれるべき好適な実施形態の詳細な説明によって明らかになる。
【００１４】
【発明の実施の形態】
まず、リレーショナル・データベース管理システム（ＲＤＢＭＳ）を用いた、本発明に係る多次元ディスク・クラスタリング用の環境を図１の文脈で説明する。システム１００はメモリ１０１に接続されたプロセッサ１０２、少なくとも１つの入出力（Ｉ／Ｏ）装置１０４、およびＲＤＢＭＳ１０３を備えている。プロセッサ１０２は本発明に係る方法を実装しうるという点を認識すべきである。あるいは、ＲＤＢＭＳ１０３が自分用のプロセッサ、メモリ、およびＩ／Ｏ装置から成る構成（図示せず）を備えて本発明に係る方法を実装してもよい。この構成では、たとえばサーバ・プラットフォームにＲＤＢＭＳ１０３を常駐させ、プロセッサ１０２、メモリ１０１、およびＩ／Ｏ装置１０４をクライアント・システム中のプロセッサ１０２に付随させてもよい。無論、当業者が容易に認識しうるように、本発明の本旨と範囲のうちでＲＤＢＭＳ１０３を用いて照会を処理しうるように適合した構成は他にも数多くある。
【００１５】
メモリ１０１はたとえばプロセッサ１０２が自分が使用した情報を格納する際に使用する。Ｉ／Ｏ装置１０４にはキーボード、マウス、および／または、ユーザが照会および／または他のデータをシステム１００に入力するのを可能にする他の任意のデータ入力装置がある。（「Ａおよび／またはＢ」は「ＡおよびＢ、Ａ、またはＢ」を表わす。）Ｉ／Ｏ装置１０４にはディスプレイ、プリンタ、および／または、照会に付随する結果および／または他のプロセッサ動作をユーザが閲覧（観察）するのを可能にする他の任意の出力装置がある。ＲＤＢＭＳ１０３はＳＱＬ（構造化照会言語）コマンド（あるいは他の種類の照会）を処理するシステム・ソフトウェア（たとえば図２に示すようにもの）を備えている。上記処理には、たとえばＳＱＬコマンド（あるいは他の種類の照会）を最適化すること、それらを実行してプロセッサ１０２に戻された情報を取得することなどがある。理解すべき点を挙げると、ＲＤＢＭＳ１０３に付随する構造化データは複数の行と列を備えた個々の表中に編成されている。次に動作を説明する。普通の構成では、Ｉ／Ｏ装置１０４として標準のコンピュータ・キーボードおよび／またはポインティング・デバイスなどを使用しているエンドユーザが特定のＳＱＬコマンドを入力する（あるいは特定のＳＱＬコマンドを生成させる）。次いで、プロセッサ１０２がＩ／Ｏ装置１０４からこのコマンドを受け取ったのち、それをＲＤＢＭＳ１０３に送る。次いで、ＲＤＢＭＳ１０３は上記ＳＱＬコマンドを解析し、解析結果を最適化し、それをＲＤＢＭＳ自身が内蔵している情報に対して実行する。次いで、ＲＤＢＭＳ１０３は結果表をプロセッサ１０２に送り返す。プロセッサ１０２は当該結果表をＩ／Ｏ装置１０４を使用しているエンドユーザに表示する。しかしながら認識すべき点を挙げると、ＲＤＢＭＳ１０３と対話する方法はこれ以外にも多数ある。たとえば、バッチ・モードで実行しているコンピュータ・プログラムは、ユーザの直接的な対話を必要とせずにＲＤＢＭＳ１０３と対話することができる。
【００１６】
認識すべき点を挙げると、ここで使用している用語「プロセッサ」はたとえばＣＰＵ（中央処理装置）を含む任意の処理装置を含むことを意図している。ここで使用している用語「メモリ」はプロセッサすなわちＣＰＵに付随するメモリ、たとえばＲＡＭ、ＲＯＭ、固定記憶装置（たとえばハード・ディスク駆動装置）、着脱可能記憶装置（たとえばディスケット）などを含むことを意図している。さらに、ここで使用している用語「入出力装置」すなわち「Ｉ／Ｏ装置」は、たとえば照会を作成するおよび／または処理装置にデータを入力する少なくとも１つの入力装置（たとえばキーボード）、および／または、照会結果および／または処理装置に付随する他の結果を提示する少なくとも１つの出力装置（たとえばＣＲＴディスプレイおよび／またはプリンタ）を含むことを意図している。あるプロセッサに付随する様々な構成要素は他のプロセッサが共用することができる、という点も理解すべきである。以上のとおりであるから、ここで説明する本発明の手法を実行する命令すなわちコードを含むソフトウェア・コンポーネントは、プロセッサに付随する少なくとも１つの記憶装置（たとえばＲＯＭ、固定記憶装置、着脱可能記憶装置など）に格納しておき、使用しうる状態になったら一部または全部を（たとえばＲＡＭ）にロードし、ＣＰＵが実行する。
【００１７】
図１に示す典型的な環境は本発明を限定することを意図していない、ということは当業者が容易に理解しうる点である。本発明の本旨と範囲の内で他の代替可能な環境を用いることもできる、ということも当業者が容易に認識しうる点である。
【００１８】
図２は典型的なＲＤＢＭＳ１０３を示す図である。ＲＤＢＭＳ１０３は照会コンパイラ２０１、コード・ジェネレータ２０２、実行エンジン２０３、アクセス・メソッド・エンジン２０４、バッファ・マネージャ２０５、ユーティリティ・エンジン２０６、データ・マネージャ２０７、および残余コンポーネント２０８を備えている。
【００１９】
本発明の好適な実施形態では、ＲＤＢＭＳ１０３としては、インターナショナル・ビジネス・マシーンズ・コーポレーションがＵＮＩＸ（Ｒ）、ＷＩＮＤＯＷＳ（Ｒ） ＮＴその他のシステム用に提供しているＤＢ２製品を用いることができる。しかしながら、認識すべき点を挙げると、本発明はＤＢ２製品であれ他の製品であれそれに付随する任意のリレーショナル・データベース・ソフトウェアに適用することができる。
【００２０】
動作中、ＲＤＢＭＳ１０３はたとえばコンピュータ・システムで実行され、ネットワーク・インタフェースを用いて少なくとも１つのクライアントと通信する。ＲＤＢＭＳ１０３はユーザからコマンドを介して命令を受け取ることにより、スタンドアロン・サーバ・モードで動作することもできる。通常、クライアント／ユーザがＲＤＢＭＳ１０３が処理するＳＱＬコマンドを発行すると、結果が返される。動作中、照会コンパイラ２０１は入力ＳＱＬコマンドを解析したのち、コード・ジェネレータ２０２を使って実行計画を作成する。解析したＳＱＬコマンドは通常、内部表現に変換したのち、最適化する。最適化には正しい結果を得るために代替可能なストラテジー（戦略）をいくつか参照するステップと、最も効率的なストラテジーを選択するステップとが含まれる。実行エンジン２０３は実行計画を解釈・実行して所望の結果を生成する。その際、実行エンジン２０３はデータ・マネージャ２０７に要求を出して表から情報を取得する。これは利用可能な索引を使い、表群をスキャンし、など、照会コンパイラ２１０（または別個の最適化プログラム）が決めた方法で行なう。実行エンジン２０３はアクセス・メソッド・エンジン２０４を使い、当該アクセス・メソッド・エンジン２０４（または外部）に格納されている基礎データベース表群に効率的にアクセスする。次いで、関連するデータ項目を取得してバッファ・マネージャ２０５に格納し当該データの再利用に備える。通常、リレーショナル・データベース管理システムは順次表スキャン方式に加え、索引基準表アクセス方式を備えている。ＲＤＢＭＳシステムでは、Ｂツリー索引が最も好適な索引手法である。また、ＲＤＢＭＳシステムのなかには、少なくとも１つの列（または索引）を用いて基礎データをクラスタ化すること、および／または区分することができるものもある。
【００２１】
本発明によると、ここで説明する多次元クラスタリング手法は次に示すＲＤＢＭＳ１０３の主要コンポーネントに影響を及ぼす。
【００２２】
（１）データ・マネージャ２０７とアクセス・メソッド・エンジン２０４：データにアクセスするために、Ｂツリー索引手法を変更するのに加え、新たなデータ設計とレコード管理構造をいくつか提供する。また、コンカレント・アクセスとデータ構造の復旧とを管理する手法を新たにサポートする。
【００２３】
（２）実行エンジン２０３：データ・マネージャ２０７とアクセス・メソッド・エンジン２０４に生じた変化を利用する、照会処理用の演算子とデータベース保守操作とを新たに提供する。
【００２４】
（３）照会コンパイラ２０１とコード・ジェネレータ２０２：新たな演算子と既存の演算子との間で選択を行なうコスト基準の新たな手法を提供する。
【００２５】
（４）ユーティリティ・エンジン２０６：ユーティリティ操作を実行する新たな方式、たとえばバルク（大量）ロードやデータ認識などを提供する。
【００２６】
一般に、ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群は、コンピュータ読み取り可能な媒体すなわちコンピュータによって読み取ることのできる媒体に有形的に記録することができる。ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群はすべて、コンピュータ・システムによって読み取られて実行されると、本発明を実装および／または使用するのに必要なステップを当該コンピュータ・システムに実行させる命令群から構成されている。ＲＤＢＭＳ１０３ソフトウェアおよびそれに由来する命令群は、オペレーティング・システムの制御の下で、適切なデータ記憶装置から実動中に使用される、コンピュータ・システムのメモリにロードする。
【００２７】
図３は２次元にクラスタ化された典型的な多次元表を示す図である。図３に示す多次元表は「年月（YearAndMonth）」３００なる次元と「州（Province）」３１０なる次元にクラスタ化されている。多次元表中のレコードはブロック群に格納されている。各ブロックはディスクその他好適な媒体に格納された連続ページから成るある分量のエクステントを保有している。（エクステントとは記憶媒体上で１つのデータ・セットが占める領域のことである。）図３では、ブロックは長円で表されており、多次元表に割り当てられたエクステント群の論理順序に従って番号が付されている。たとえば、長円３０１は多次元表中の１番目のブロックすなわちブロック１を指示している。図３中の格子はこれらのブロックの論理区分化を表わしている。各正方形（たとえば正方形３０２）は論理セルを表わしている。格子中の行または列は特定の次元に対するスライスを表わしている。（スライスとはある事象から切り出された薄片のことである。）たとえば、州３１０列中の値「ＯＮ」（「オンタリオ（Ontario)」の略）を含むレコードはすべて、格子中の「ＯＮ」列によって画定されたスライスに含まれるブロック群に存在する。実際、このスライス中の各ブロックは州フィールドが「ＯＮ」であるレコードしか含んでいない。したがって、格子中のこのスライスすなわちこの列に、あるブロックが含まれるのは、州フィールドが「ＯＮ」であるレコードを当該ブロックが含んでいる場合だけである。図３に示す典型的な多次元表では、「ＯＮ」州列に対するスライスにはブロック９、１６、１８、１９、２２、２４、２５、３０、３６、３９、４１、４２が含まれている。
【００２８】
ここに示す典型的な表ではブロック１から開始する順番でブロック群に番号を付したけれども、他の多くの方法でブロック群を特定しうるということを認識すべきである。たとえば、表中の１番目のブロックはブロック０と名付けることもできる。また当業者が認識しうるように、本発明の本旨と範囲の内で、表に関係する情報の部分を特定する他の様々な方法を案出することができるとともに、異なる用語法を用いることもできる。
【００２９】
図４は図３の典型的な多次元表の各次元に次元ブロック索引を備えた図である。あるスライスを構成しているのはどのブロックであるか、すなわち特定の次元キー値を有するレコードをすべて含むのはどのブロックであるかを判断するのを容易にするために、表を生成するときに各次元ごとに次元ブロック索引を自動的に生成する。したがって、年月次元３００には次元ブロック索引４００を生成し、州次元３１０には次元ブロック索引４１０を生成する。各次元ブロック索引は既存のレコード基準索引と同じ方法で構築することができる。ただし、リーフ（葉）のレベルでは、キーはレコードＩＤ（ＲＩＤ）ではなくブロックＩＤ（ＢＩＤ）を指示している。都合のよいことに、各ブロックはレコード群から成る多数のページを潜在的に含んでいるから、これらのブロック索引はＲＩＤ索引よりもはるかに小さい。また、これらのブロック索引は新たなブロックが必要になりそれをセルに付加するとき、またはセルから除去しうるように既存のブロックを空（から）にするときに更新するだけでよい。
【００３０】
スライス（すなわちある次元における特定のキー値を有するレコードをすべて備えたページ群を含むブロック群の集合）は、関連する次元ブロック索引中に当該キー値に対するＢＩＤリストによって表わすことができる。
【００３１】
図４に示す典型的な多次元表において、州次元が「ＯＮ」であるレコードをすべて含むスライスを探すには、州次元ブロック索引でこのキー値を調べる。すると、次に示すキーが見つかる。
＜ＯＮ：９、１６、１８、１９、２２、２４、２５、３０、３６、３９、４１、４２＞
ただし、キーは＜キー値：ＢＩＤ＞対という形をしている。
【００３２】
上記キーはキー値（すなわち「ＯＮ」）とＢＩＤのリストから構成されている。各ＢＩＤはブロックの場所を含んでいる。この例では、列挙されているブロック番号は多次元表の格子中にある「ＯＮ」列（すなわちスライス）中にあるものと同じであることが分かる。同様に、年月次元が「９９０２」であるレコードをすべて含むブロックのリストを探すには、年月次元索引でこのキー値を調べると、次に示すキーが見つかる。
＜９９０２：２、５、７、８、１４、１５、１７、１８、３１、３２、３３、４３＞
【００３３】
多次元表のクラスタリングはＳＱＬ言語で特定することができる。それには、Ｃｒｅａｔｅ Ｔａｂｌｅ（表作成）ステートメントまたはＡｌｔｅｒ Ｔａｂｌｅ（表変更）ステートメントに付加する文節に、クラスタリング属性を特定しうる適切なものを使用する。たとえば、次に示すＣｒｅａｔｅ Ｔａｂｌｅステートメントを用いてこの例の表を作成することができる。
CREATE TABLE TABLE＿1 (Date DATE, Province CHAR(2),
YearAndMonth INTEGER
DIMENSIONS (YearAndMonth, Province);
【００３４】
この場合、年月（YearAndMonth）次元と州（Province）次元はTABLE ＿1 用にDIMENSIONS文節を用いて定義されている。多次元表のクラスタリングは当該多次元表中のすべてのデータに適用されなければならない。特に、既存の表にＡｌｔｅｒ Ｔａｂｌｅコマンドを用いてクラスタリングを特定する場合には、データの再編成も実行する必要がある。留意点を挙げると、クラスタリング属性用のブロック索引は自動的に作成することができる。
【００３５】
図５は典型的な複合次元索引用のデータ構造を示す図である。レコードを表に挿入するとき、その次元値用のセルが既に存在するかどうか知る必要がある。上記セルが存在する場合、可能なら当該レコードを上記セルの既存のブロックに挿入し、既存のブロックが満杯なら上記セルに別のブロックを付加する。上記セルが存在しない場合には、新たなセルを作成しそれにブロックを付加する必要がある。これを自動的な保守操作とするには、複合次元索引と呼ばれ多次元表を作成するときに作成しうるブロック索引を新たに用いて実装することができる。この複合次元索引は多次元表中のすべての次元列について作成するから、各キー値は表中の特定のセルに対応し、そのＢＩＤリストは当該セルを構成するブロックから成る。これを図５に示す。この複合ブロック索引によって、次元用の値の特定の集合を有するブロックを迅速かつ効率的に検索するのが容易になる。複合ブロック索引は挿入操作中に、対象とする多次元表の次元群によるデータの物理的クラスタリングを動的に管理・保守するのにも使うことができる。認識すべき点を挙げると、Ｒツリーなどの多次元索引構造も、それらがレコードまたはオブジェクトではなくブロックを指示している場合には、複合次元索引を実装するのに使用することができる。
【００３６】
図６は図４の多次元表に新たな次元を備えて拡張したものを示す図である。いま、図６に示すように、年月次元３００、州次元３１０、および色（Color)次元６００から成る次元を備えた多次元表を考える。この多次元表は論理立方体と考えることができる。この例では、４つのブロック索引を作成することになる。すなわち、個々の次元（すなわち年月次元３００、州次元３１０、および色次元６００）ごとに１つずつのブロック索引と、キーとしてこれらの次元のすべてを備えた複合次元索引（図示せず）とである。
【００３７】
本発明の目標の１つは効率的な照会処理を容易にすることである。以下、本発明によって容易になる照会処理方法を説明する。年月次元３００、州次元３１０、および色次元６００から成る次元を備えた、図６に示す３次元立方体を考える。たとえば「すべての日付と地域にわたって「色が『赤』である」合計売上高はいくらか」のような照会は、いくつかの異なる方法で処理することができる。この照会を処理する方法には、次に示す選択肢がある。
（１）表スキャン：表全体をスキャンして「色が『赤』である」行だけを選択する。
（２）ブロック・スキャン：色に関するブロック索引を使って検索範囲をブロックの特定の集合に狭める。
（３）レコード・スキャン：（存在する場合には）色に関するレコード基準索引を使って検索範囲をレコードの特定の集合に狭める。
【００３８】
照会最適化プログラムでコスト・モデルを用いることにより、これらの選択肢のうちから最良のものを見つけ出すことができる。ブロック・スキャン方法は本発明で導入された新しい操作である。このブロック・スキャンは次に示す２つのステップで実行する。
(i) ブロック索引をスキャンして照会述語を満たすブロックＩＤを見つけ出す。
(ii)当該ブロック中のレコードをすべて処理する。
これは余分な述語を含んでいてもよい。ブロック・スキャン操作が最も効率的なのは、所定の照会に対して１つのブロック、ブロックの集合、またはレコードの集合の大部分を処理する必要がある場合である。このような要件はデータウェアハウスではきわめて普通のことである。たとえば、上述した照会はブロックの全体集合へのアクセスを含むものと考えられる。したがって、この照会を処理する方法としては、ブロック・スキャン操作が最も効率的な方法になると考えられる。
【００３９】
留意点を挙げると、多次元表に対してＲＩＤ索引もサポートすれば、索引ＡＮＤ手法および索引ＯＲ手法によってＲＩＤ索引とブロック索引とを組み合わせることができる。あるいは、多次元表を既存の任意の表と同様に処理することもできる。たとえば、多次元表に対してトリガー、参照保全性、ビュー、および自動サマリー表を定義することができる。
【００４０】
図７（ａ）（ｂ）（ｃ）はブロック索引を用いて索引ＡＮＤを実行する方法を示す図である。いま、図６に示す３次元立方体に対する「色が『青』であり、かつ（ＡＮＤ）、州が『ＱＢ』である」という照会を考える。まず、「色が『青』である」ブロックをすべて含むスライスを求める。それには、多次元表に付随する色次元ブロック索引で「青」キー値を探す。その結果、次に示すキーが見つかる。
＜青：１、２、３、４、５、６、７、８、９、１０、１１、１２、１３、１４＞
これは図７（ａ）の立体図に示す（灰色で強調表示した）スライス７１５に対応している。
【００４１】
次いで、「州が『ＱＢ』である」レコードをすべて含むブロックを求める。それには、州次元ブロック索引で「ＱＢ」キー値を探す。その結果、次に示すキーが見つかる。
＜ＱＢ：１１、１２、１３、１４、２７、２８、３５、３７、４０、５１＞
これは図７（ｂ）の立体図に示すスライス７２５に対応している。上記２つのキー値を有するレコードをすべて含むブロックの集合を探すには、上記２つのスライスの交差部を見つける必要がある。これを行なうには、上記２つのＢＩＤリストの索引ＡＮＤをとる。この例では、共通ＢＩＤ値は「１１、１２、１３、１４」である。これは図７（ｃ）に示す立体図の区画７３５に対応している。
【００４２】
スキャンすべきブロックのリストが得られたら、各ブロックに対してミニ・リレーショナル・スキャンを実行するだけでよい。この操作には入出力（Ｉ／Ｏ）が１回しかない（したがって高速に行なうことができる）。なぜなら、１つのブロックはディスクに１つのエクステントとして格納され、１つの単位としてバッファプールに読み取ることができるからである。また、照会述語を再適用する必要があり、かつ、一部の述語が次元値にしか存在しない場合には、それらの述語をブロック中の１つのレコードに再適用するだけでよい。なぜなら、ブロック中のすべてのレコードに同じ次元キー値が存在することが保証されているからである。また、他に述語があっても、それらがブロック中の残りのレコードに存在するかどうか検査するだけでよい。
【００４３】
ブロック基準索引ＡＮＤ方式はビット・マップ方式を用いることができるから、きわめて効率的である。また、ブロック・レベル索引はＲＩＤ索引よりも小さいから、索引ＡＮＤに要する処理時間はきわめて少ない。最後に、ブロックの交差リストはブロック基準Ｉ／Ｏ操作を使って効率的にアクセスすることができる。全体として、ここで説明した操作はきわめて効率的であり、この手法以前の既存のものよりもはるかに高速である。
【００４４】
多次元表用に既存のＲＩＤ基準索引もサポートすれば、索引ＡＮＤ操作と索引ＯＲ操作によってＲＩＤ索引とブロック索引とを組み合わせることができる。
【００４５】
上述したように、ブロック索引を用いてブロック基準索引ＯＲ操作も実行することができる。たとえば、照会が「州が『ＯＮ』であるか、または（ＯＲ）、州が『ＢＣ』である」という条件を含んでいる場合、州ブロック索引をカテゴリごとにスキャンしたのち、ＯＲ操作を実行するとブロックの合計リストが得られる。また、このＯＲ操作によれば、たとえば「州が『ＡＢ』であるか、または（ＯＲ）、色が『赤』である」といった条件の場合に生じる可能性のあるＢＩＤの重複を除去することができる。
【００４６】
副ブロック索引スキャンもサポートすることができる。副ブロック索引があると、単一のＢＩＤが多数のキーの下に存在しうることになる。このことはＲＩＤ索引では決してありえない、ということに留意する必要がある。副ブロック索引を用いてファクト表にアクセスする際に重要なのは、適格ブロックのスキャンが１回しかないという点である。すなわち、その１回のスキャンで適格ブロックのすべてのレコードにアクセスする必要があり、当該ブロックを再度フェッチしてはならない。この結果、重複を除去しうるようにブロックの適格リストを保守することが必要になる。
【００４７】
図８は多次元表に付随する典型的なブロック・マップを示す図である。ブロック・マップには、特定の多次元表に属す各ブロックの現在の状態が記録されている。たとえば、このブロック・マップ中の要素８０１は多次元表のブロック０を表わしている。その使用可能状態は「Ｘ」であり、予約済みであることを表わしている。したがって、ブロック０は多次元表のデータ行を格納するのにまったく使用できない。ブロック・マップ中の要素８０２はブロック８を表わしている。その使用可能状態は「Ｕ」であり、使用中であることを表わしている。同様に、ブロック１〜７、１０〜１５、１７、２０、２５、２６も使用中である。このことは多次元表中のレコードはこれらのブロック中に存在するということを意味している。ブロック・マップ中の要素８０３はブロック１９を表わしている。その使用可能状態は「Ｆ」であり、空（から）であることを表わしている。同様に、ブロック２１、２３、２４、２７〜２９も空である。このことはこれらのブロックが現在、多次元表によって使用されておらず、使用可能であることを意味している。ブロック・マップ中の要素８０４はブロック２２を表している。その使用可能状態は「Ｌ」であり、当該ブロックは最近に情報がロードされたことを表わしている。同様に、ブロック９、１６、３０〜３３も最近にロードされたブロックである。ブロック・マップ中の要素８０６はブロック１８を表わしている。その使用可能状態は「Ｃ」である。ブロック１８は以前にロードされたものであるが、依然として制約検査を行なう必要がある。
【００４８】
認識すべき点を挙げると、図８に示すブロック・マップは特定の値を有する様々な状態フラグを備えているけれども、他の値を用いて異なるブロック状態または新たなブロック状態を反映させることもできる。さらに認識すべき点を挙げると、新たなブロックその他の情報を表わす新たな要素を動的に割り当てうるような方法で、ビット・マップのデータ構造を構築することもできる。
【００４９】
各ブロックは当該ブロックの第１ページの第１スロットに配置されたヘッダを備えている。ヘッダには（他の様々な事項とともに）ブロック状態のコピーとビット・マップとが格納されている。ブロック状態のコピーが格納されている結果、ブロック・マップが削除されたり破損されたりした場合、必要なら当該ブロック・マップを再作成することができる。上記ビット・マップはブロックの全ページをカバーし空のページを指示するものである（たとえば０＝空、１＝非空、オーバーフロー・レコードまたはポインタ・レコードしか備えていない場合であってもこのようにする）。また、各ブロックはそれに付随するフリー・スペース・コントロール・レコード（ＦＳＣＲ）を備えている。ＦＳＣＲにはページ・オフセットとページ当たりのフリー・スペースの近似値とが格納されている。これらのＦＳＣＲはたとえば、ブロックの第１ページに位置し、当該ページの第２レコードとして格納される。
【００５０】
上述した表編成はきわめてスペース効率が良い。重要なのは、各セルが少なくとも１ブロック分のデータを有するように多次元キーおよび対応するブロック・サイズを選ぶことである。というのは、最終ブロックのみが部分的に満杯になることが多いからである。この高効率状態は挿入操作、削除操作、またはバックグラウンドでの再編成が頻繁に行なわれる場合であっても維持することができる。これに対して、ＯＬＡＰ編成では上述したように、大量の未使用スペースが生じる。
【００５１】
図９は本発明の手法に従って実行しうる様々な保守機能を示す図である。図９には保守機能９００がある。保守機能９００には、ロード機能９０１、再編成機能９０２、挿入機能９０３、削除機能９０４、パージ機能９０５、および更新機能９０６がある。以下、これらの機能を詳細に説明する。
【００５２】
〔ロード機能９０１〕
通常、比較的大量のデータを表中にロードするには、挿入コマンドを多数個発行する代わりにロード機能を使用する。ロード・ユーティリティを用いれば、特定の方式でフォーマットしたデータ・セットにアクセスし、当該データ・セット中の情報を使って特定の表に行を作成することができる。
【００５３】
重要な点を挙げると、ロード・ユーティリティは効率的な方式を用いてデータを表中に挿入する。多次元表中にデータを首尾よくロードするには、入力を次元値とともに編成することである。（このことは多次元表では初期設定として確立されている。）このことが必要なのは、レコードが次元値とブロック境界によって適切にクラスタ化されていることを保証するためである。たとえば、＜年月＝９９０３、州＝「ＯＮ」、色＝「赤」＞に対応する論理セルに対して１つのビン（大箱）を作成することができる。そうすると、次元属性に関し同じ値を有するレコードはすべてこのビンに割り当てることができる。物理的には、各ビンはデータ・ページ群から成る１つのブロックによって表わすことができる。最近に処理されたビンはメモリ中に保持しておき、それらが満杯になったとき、または他のビンをメモリに持ってくる必要が生じたときにディスクに書き出す。
【００５４】
処理を減らす方法の１つは、ユーザがＬＯＡＤコマンド中で文節を指定できるようにすることである。ユーザ指定の文節として、たとえば
ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ（取り込み順に変更）文節
を挙げることができる。
この任意実行文節（または同じ効果を有する同様の文節）は、入力データ・セットは既に格納順であるから処理をより効率的に行なえるということをロード・ユーティリティに知らせるのに使うことができる。これが役に立つ場合がいくつかある。たとえばデータが次元とキー値によって格納済みの場合である。この場合、ロード・ユーティリティは順番を検証するだけでよい。別の例として、特定のセル用のレコード群をロードする場合に有益である。なぜなら、特定のセルに付加するレコード群の次元値はすべて同じだからである。これが当てはまる例として、表が単一の次元から成り、当該次元の特定値を有するレコード群（たとえば２００１年２月以降の全レコード）にユーザが大童（おおわらわ）になっている場合が挙げられる。このような場合、ＭＯＤＩＦＹ ＢＹ ＡＳＳＥＲＴＯＲＤＥＲ文節（またはこれと同じ効果を有する同様の文節）を指定すると、ロード・ユーティリティはデータが適切に順序付けられていることを検証するだけでよい。順番が前後したレコードを発見した場合には、ロード・ユーティリティは処理を停止し、たとえば当該表をロード保留状態に置いておけばよい。
【００５５】
〔再編成機能９０２〕
再編成ユーティリティはデータベースにおけるデータの物理的な配置を再編成するのに使用する。データベースの再編成が必要になるのは、フラグメント（断片）化したデータ・スペースをデフラグするため、またはクラスタ索引を有するレコード群を再構成（クラスタ化）するためである。
【００５６】
多次元表の再編成はクラスタリング索引を有する表の場合よりもずっと単純であり、必要になる頻度もずっと低い。多次元表ではクラスタリングを自動的かつ連続的に継続することができるから、データを再クラスタ化するのにもはや再編成を必要としない。しかし、多次元表中のスペースを再利用する（具体的にはセル内のスペースを再利用する）、あるいはオーバーフローしたレコードを除去するのに、再編成ユーティリティを使うことができる。多次元表用の再編成ユーティリティはブロック指向である。複合次元ブロック索引を使うことにより、特定ブロック群中のレコード群にアクセスすることができる。それらのレコード群は再編成パラメータ（たとえば必要な空きスペースの量）を用いてを新たなブロック１つに再構成することができる。この結果、初期論理セルが多数のブロックを含んでいても、再構成後のセルはより少ない数のブロックしか含んでいない、ということが起こりうる。たとえば、あるセルが初めにブロック１、１０、３０、４５を含んでいたとする。この場合、再編成後に当該セルが新たなブロック１、２しか含んでいない、ということがありうる。残りのスペースは他のセルが使用しうるように解放された、あるいはこの表から完全に除去された。また、再編成の終わりには新たなブロック・マップの再構築も行なう。
【００５７】
〔挿入機能９０３〕
挿入には表に新たなレコードを作成することが含まれる。挿入操作中、クラスタリングを維持する必要がある。いま、次元値＜９９０３，‘ＡＢ’＞を有するレコードを（図４に示すような）多次元表中に挿入することを考える。まず、複合ブロック索引を使ってこの新たなレコード用に適切なブロックを特定する必要がある。それには、（図５に示すような）複合ブロック索引でキー値「９９０３，ＡＢ」を探す。その結果、次に示すキーが見つかる。
＜９９０３，ＡＢ：３，１０＞
この場合、キー値「９９０３，ＡＢ」を有するブロックはブロック３とブロック１０の２つあることが分かる。これらのブロックは指定した次元を有するレコードをすべて含んでいるが、それら以外のレコードは含んでいない。したがって、これらのブロックのページのいずれかにスペースがある場合、これらのブロックのうちの１つに新たなレコードを挿入する。これらのブロックのページのいずれにもスペースがない場合には、多次元表に新たなブロックを割り当てるか、多次元表中の以前に空にしたブロックを使用する。その際、（図８に示すような）ブロック・マップを探索して空のブロックを見つけることができる。たとえば多次元表用のビット・マップを調べたら、ブロック４８が現在、多次元表によって使用されていない（すなわちその状態が空を示す「Ｆ」である）ことが分かったとする。この場合、上記新たなレコードをブロック４８のページに挿入する。そして、このブロック４８を、そのＢＩＤを複合ブロック索引に付加することによりセルに割り当てるとともに、各次元ブロック索引に割り当てる。
【００５８】
結果として得られる次元ブロック索引中のキーは次に示すようになる。
＜９９０３：３，４，１０，１６，２０，２２，２６，３０，３６，４８＞
＜ＡＢ：１，３，５，６，７，８，１０，１２，１４，３２，４８＞
結果として得られる複合ブロック索引中のキーは次に示すようになる。
＜９９０３，ＡＢ：３，１０，４８＞
【００５９】
いま、多次元表中に空のブロックがないとする。この場合には、多次元表に新たなブロックを割り当て、行（すなわちレコード）を挿入するのに使う。この場合にも、上述したようにして索引群を更新する。
【００６０】
新たな次元を有するレコードを挿入する場合には、新たなブロックまたは空のブロックを割り当てなければならない。そして、次元ブロック索引と複合ブロック索引に新たなキー値を付加する。
【００６１】
挿入機能を実行する際には、第１レコードをブロックに挿入するときに特に注意するのに加え、第１レコードをブロック中の新たなページに挿入するときにも特別の注意を払う必要がある。それには、各ブロック用のページ・ビット・マップを使ってブロック中のページの状態を保守する。そして、ページに第１レコードが挿入されたら、ページ・ビット・マップ中のビットをセットする。このページ・ビット・マップによって、ブロック中のページの占有状態を追跡することが可能になるとともに、挿入操作や削除操作の際にブロックの状態を保守することが可能になる。
【００６２】
〔削除機能９０４〕
通常の表の削除操作では表中の少なくとも１つのレコードを削除し、削除したレコードが占有していたスペースを解放する。多次元表の削除でも同じことを行なう。しかしながら、ブロック中のページの状態に加え、ブロック全体にも特に注意する必要がある。ページの最終レコードを削除する場合には、ページ・ビット・マップを更新し削除した特定のページに付随するビットをクリア（消去）する。ブロック中のページがすべて空の場合には、このページ・ビット・マップを完全にクリアする。このことは当該ブロックをブロック・マップ中で空とマーク付けしうることを示している。この空のブロックは、たとえば将来の挿入操作やロード操作によって再利用しうる。あるブロックを空にしたら、次元索引もすべて更新し、当該空にしたブロックに付随するＢＩＤを当該ブロックの次元属性に対応する特定のキーから除去する。
【００６３】
〔パージ機能９０５〕
パージとは、関係するレコードから成る大集合を削除するときに使用する特別な形の削除操作である。いま、次に示すＳＱＬステートメントを考える。
Delete from Table ＿1 where color='Red'
色（color)属性は（図６に示す多次元表の場合のように）この多次元表（Table ＿1)の１つの次元であると仮定する。したがって、「色が『赤』である」（color='Red')という制約は「赤」（Red)値に付随するブロックをすべて削除すべきことを示している。これを実行するには、色の次元ブロック索引で「赤」を検索し、付随するＢＩＤのリストを見つけ出せばよい。このリストが「１２、１７、２１、３０」であると仮定する。この多次元表（Table ＿1)にこの他に索引や関係するデータ構造がない場合、これらのブロックを当該多次元表のブロック・マップ中で空とマーク付けしたのち、ブロック索引から上記ＢＩＤを削除することができる。これはきわめて高速の操作であるとともに、ログをとるコストと索引を保守するコストを低減することもできる。
【００６４】
パージ型の削除が適用できることを検出するには、削除ステートメントを検査しその中の制約が少なくとも１つの次元文節に基づいてることを検証すればよい。特に、処理する必要のあるＢＩＤの集合を特定するのに少なくとも１つのブロック索引を用いている場合には、パージ型の削除を使用することを考慮してもよい。最適化プログラムはこれを検出し、それに従った適切な照会計画を作成することができる。留意点を挙げると、最適化プログラムは高速パージを可能にする（または不可能にする）新たな課題にも気づくことになる。これらの課題は当該多次元表に別の索引や制約があるということを意味している。
【００６５】
〔更新機能９０６〕
更新操作には表中の情報を変更することが含まれる。多次元表では、更新には次に示す２種類のものがある。
【００６６】
（１）単純更新：この場合、更新は多次元表中の次元ではない、属性すなわちフィールドにのみ適用される。したがって、行（すなわちレコード）は同じ論理セルに継続して属す。行は変化が生じても新たなスペースが必要とならない限り、同じ場所に存在し続ける。あるいは、行は同じブロック中の新たな場所または別のブロックに移動する可能性もある。このレコード（すなわち行）を移動させたときには、元の場所のＲＩＤはそのままにしておき、オーバーフロー・ポインタ手法を使って新たな場所を指示するようにする。（オーバーフロー・ポインタ手法とは旧レコードが満杯になり新レコードを作ったとき、旧レコードの末尾に新レコードの場所を指示するポインタを格納しておく手法のことである。）新たな場所が新たなブロックである場合には、次元ブロック索引に当該新たなブロックを挿入する必要がある。
【００６７】
（２）次元列の更新：更新が少なくとも１つの次元列に対するものである場合、内部的にはこれを削除と挿入として扱う必要がある。この結果、（更新対象の次元列の）レコードは更新後は新セル中でクラスタ化されているということが保証される。なぜなら、当該レコードは旧セルに属すブロック中には配置できないからである。この操作を実行するには、上述した削除手法と挿入手法とを組み合わせる。
【００６８】
以上、添付図面を参照して本発明の説明目的の実施形態を説明してけれども、理解すべき点を挙げると、本発明はそれら明確な実施形態に限定されず、また、本発明の範囲または本旨の内で当業者は他の様々な変形および変更をなすことができる。
【００６９】
まとめとして以下の事項を開示する。
（１）
リレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法であって、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられている、ステップと
を備えた
方法。
（２）
前記少なくとも１つのブロックの各々が連続記憶スペースから成る、
上記（１）に記載の方法。
（３）
前記少なくとも１つのブロック索引の各々が、少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、
上記（１）に記載の方法。
（４）
前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、
上記（１）に記載の方法。
（５）
前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、
上記（１）に記載の方法。
（６）
前記表が多次元表である、
上記（１）に記載の方法。
（７）
前記多次元表が用途情報を格納するのに使用されている、
上記（６）に記載の方法。
（８）
前記用途情報がデータウェアハウス用のものである、
上記（７）に記載の方法。
（９） さらに、
前記多次元表用の複合次元索引を作成するステップ
を備えた、
上記（６）に記載の方法。
（１０）
前記複合次元索引を作成するステップを自動的に実行する、
上記（９）に記載の方法。
（１１）
前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられているとともに、前記セル用に少なくとも１つのブロックＩＤのリストを備えている、
上記（９）に記載の方法。
（１２） さらに、
前記表用にブロック・マップを作成するステップ
を備え、
前記ブロック・マップの各要素が前記少なくとも１つのブロックの１つ用に状態情報を備えている、
上記（１）に記載の方法。
（１３）
前記少なくとも１つのブロックの各々が状態情報の複製を備えている、
上記（１２）に記載の方法。
（１４）
前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、
前記ブロック・マップを作成する、
上記（１３）に記載の方法。
（１５） さらに、
前記表に格納された情報を求める照会を処理するステップ
を備えた、
上記（１）に記載の方法。
（１６）
前記照会を処理するステップが、
前記少なくとも１つのブロック索引および前記複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップ
を備えた、
上記（１５）に記載の方法。
（１７）
前記照会を処理するステップが、
前記表全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップ
の少なくとも一方を
備えた、
上記（１５）に記載の方法。
（１８）
前記照会を処理するステップが、
索引ＡＮＤ
を備えている、
上記（１５）に記載の方法。
（１９）
前記照会を処理するステップが、
索引ＯＲ
を備えている、
上記（１５）に記載の方法。
（２０）
前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップと
を備えている、
上記（１５）に記載の方法。
（２１） さらに、
保守要求を処理するステップ
を備えた、
上記（１）に記載の方法。
（２２）
前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新
のうちの１つを求める要求から成る、
上記（２１）に記載の方法。
（２３）
前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、
上記（２１）に記載の方法。
（２４）
ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップ
のうちの一方
を備えている、
上記（２２）に記載の方法。
（２５）
再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップ
を備えている、
上記（２１）に記載の方法。
（２６）
機械によって読み取り可能なプログラム記憶装置であって、前記プログラム記憶装置ちはリレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法を実行する、前記機械で実行可能な命令群から成るプログラムが有形的に記録されており、前記方法が、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられている、ステップと
を備えている
プログラム記憶装置。
（２７）
前記少なくとも１つのブロックの各々が連続記憶スペースから成る、
上記（２６）に記載のプログラム記憶装置。
（２８）
前記少なくとも１つのブロック索引の各々が、少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、
上記（２６）に記載のプログラム記憶装置。
（２９）
前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、
上記（２６）に記載のプログラム記憶装置。
（３０）
前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、
上記（２６）に記載のプログラム記憶装置。
（３１）
前記表が多次元表である、
上記（２６）に記載のプログラム記憶装置。
（３２）
前記多次元表が用途情報を格納するのに使用されている、
上記（３１）に記載のプログラム記憶装置。
（３３）
前記用途情報がデータウェアハウス用のものである、
上記（３２）に記載のプログラム記憶装置。
（３４） さらに、
前記多次元表用の複合次元索引を作成するステップ
を備えた、
上記（３１）に記載のプログラム記憶装置。
（３５）
前記複合次元索引を作成するステップを自動的に実行する、
上記（３４）に記載のプログラム記憶装置。
（３６）
前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられているとともに、前記セル用に少なくとも１つのブロックＩＤのリストを備えている、
上記（３４）に記載のプログラム記憶装置。
（３７） さらに、
前記表用にブロック・マップを作成するステップ
を備え、
前記ブロック・マップの各要素が前記少なくとも１つのブロックの１つ用に状態情報を備えている、
上記（２６）に記載のプログラム記憶装置。
（３８）
前記少なくとも１つのブロックの各々が状態情報の複製を備えている、
上記（３７）に記載のプログラム記憶装置。
（３９）
前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、
前記ブロック・マップを作成する、
上記（３８）に記載のプログラム記憶装置。
（４０） さらに、
前記表に格納された情報を求める照会を処理するステップ
を備えた、
上記（２６）に記載のプログラム記憶装置。
（４１）
前記照会を処理するステップが、
前記少なくとも１つのブロック索引および前記複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップ
を備えた、
上記（４０）に記載のプログラム記憶装置。
（４２）
前記照会を処理するステップが、
前記表全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップ
の少なくとも一方を
備えた、
上記（４０）に記載のプログラム記憶装置。
（４３）
前記照会を処理するステップが、
索引ＡＮＤ
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４４）
前記照会を処理するステップが、
索引ＯＲ
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４５）
前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップと
を備えている、
上記（４０）に記載のプログラム記憶装置。
（４６） さらに、
保守要求を処理するステップ
を備えた、
上記（２６）に記載のプログラム記憶装置。
（４７）
前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新
のうちの１つを求める要求から成る、
上記（４６）に記載のプログラム記憶装置。
（４８）
前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、
上記（４６）に記載のプログラム記憶装置。
（４９）
ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップ
のうちの一方
を備えている、
上記（４７）に記載のプログラム記憶装置。
（５０）
再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップ
を備えている、
上記（４６）に記載のプログラム記憶装置。
【図面の簡単な説明】
【図１】 本発明の手法で用いる典型的な環境のブロック図である。
【図２】 本発明に係る典型的なリレーショナル・データベース管理システムの模式図である。
【図３】 本発明の一実施形態に係る２次元にクラスタ化した典型的な多次元表の模式図である。
【図４】 本発明の一実施形態に係り図３の典型的な多次元表に各次元に関する次元索引を備えたものの模式図である。
【図５】 本発明の一実施形態に係る典型的な複合次元索引の模式図である。
【図６】 本発明の一実施形態に係り図３の典型的な多次元表を第３の次元に拡張したものの模式図である。
【図７】 （ａ）〜（ｃ）は本発明の一実施形態に係る索引ＡＮＤ手法の模式図である。
【図８】 本発明の一実施形態に係る典型的なブロック・マップの模式図である。
【図９】 本発明の一実施形態に係る様々な典型的な保守機能の模式図である。
【符号の説明】
１００ システム
１０１ メモリ
１０２ プロセッサ
１０３ ＲＤＢＭＳ
１０４ 入出力（Ｉ／Ｏ）装置
２０１ 照会コンパイラ
２０２ コード・ジェネレータ
２０３ 実行エンジン
２０４ アクセス・メソッド・エンジン
２０５ バッファ・マネージャ
２０６ ユーティリティ・エンジン
２０７ データ・マネージャ
２０８ 残余コンポーネント
３００ 年月次元
３０１ 長円（ブロック）
３０２ 正方形（セル）
３１０ 州次元
４００ 次元ブロック索引
４１０ 次元ブロック索引
６００ 色次元
７１５ スライス
７２５ スライス
７３５ 区画
９００ 保守機能
９０１ ロード機能
９０２ 再編成機能
９０３ 挿入機能
９０４ 削除機能
９０５ パージ機能
９０６ 更新機能
Claims (42)
- リレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法であって、
コンピュータ・システムが、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられ、前記少なくとも１つのブロック索引の各々が、前記ブロックの位置を含む少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、ステップと、
前記表に付随するブロック・マップを作成するステップであって、前記ブロック・マップの要素の各々が前記少なくとも１つのブロックの１つ用に状態情報を備え、前記少なくとも１つのブロックの各々が状態情報の複製を備え、前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、前記ブロック・マップを作成する、ステップと、を備えた方法。 - 前記少なくとも１つのブロックの各々が連続記憶スペースから成る、請求項１に記載の方法。
- 前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、請求項１に記載の方法。
- 前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、請求項１に記載の方法。
- 前記表が多次元表である、請求項１に記載の方法。
- 前記多次元表が用途情報を格納するのに使用されている、請求項５に記載の方法。
- 前記用途情報がデータウェアハウス用のものである、請求項６に記載の方法。
- さらに、前記コンピュータ・システムが、
前記多次元表のための複合次元索引を作成するステップを備えた、請求項５に記載の方法。 - 前記複合次元索引を作成するステップを自動的に実行する、請求項８に記載の方法。
- 前記複合次元索引が複合キーのリストを備え、各複合キーが前記多次元表のセルに関連付けられているとともに、前記セルのために少なくとも１つのブロックＩＤのリストを備えている、請求項８に記載の方法。
- さらに、前記コンピュータ・システムが、
前記表に格納された情報を求める照会を処理するステップを備えた、請求項１に記載の方法。 - 前記照会を処理するステップが、
前記少なくとも１つのブロック索引および複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップを備えた、請求項１１に記載の方法。 - 前記照会を処理するステップが、
前記表の全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップの少なくとも一方を備えた、請求項１１に記載の方法。 - 前記照会を処理するステップが、
索引ＡＮＤを備えている、請求項１１に記載の方法。 - 前記照会を処理するステップが、
索引ＯＲを備えている、請求項１１に記載の方法。 - 前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップとを備えている、請求項１１に記載の方法。 - さらに、前記コンピュータ・システムが、
保守要求を処理するステップを備えた、請求項１に記載の方法。 - 前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新のうちの１つを求める要求から成る、請求項１７に記載の方法。 - 前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、請求項１７に記載の方法。
- ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップのうちの一方を備えている、請求項１８に記載の方法。 - 再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップを備えている、請求項１７に記載の方法。 - 機械によって読み取り可能なプログラム記憶装置であって、前記プログラム記憶装置はリレーショナル・データベースにおいてクラスタ化されたデータを効率的に保守する方法を実行する、前記機械で実行可能な命令群から成るプログラムが有形的に記録されており、前記方法が、
前記リレーショナル・データベースの表の少なくとも１つの次元を少なくとも１つの表定義パラメータを用いて特定するステップと、
前記少なくとも１つの次元の各々用のデータを少なくとも１つのブロックを用いてクラスタ化するステップと、
少なくとも１つのブロック索引を作成するステップであって、前記少なくとも１つのブロック索引の各々が前記少なくとも１つの次元に関連付けられ、前記少なくとも１つのブロック索引の各々が、前記ブロックの位置を含む少なくとも１つのブロックＩＤから成るリストに関連付けられている少なくとも１つのキーを備えている、ステップと、
前記表に付随するブロック・マップを作成するステップであって、前記ブロック・マップの要素の各々が前記少なくとも１つのブロックの１つ用に状態情報を備え、前記少なくとも１つのブロックの各々が状態情報の複製を備え、前記少なくとも１つのブロック中に備えられた前記状態情報の複製を用いて、前記ブロック・マップを作成する、ステップと、を備えているプログラム記憶装置。 - 前記少なくとも１つのブロックの各々が連続記憶スペースから成る、請求項２２に記載のプログラム記憶装置。
- 前記少なくとも１つの次元の各々が前記表の少なくとも１つの列に関連付けられている、請求項２２に記載のプログラム記憶装置。
- 前記少なくとも１つの表定義パラメータが表作成ステートメントまたは表変更ステートメントに関連付けられている、請求項２２に記載のプログラム記憶装置。
- 前記表が多次元表である、請求項２２に記載のプログラム記憶装置。
- 前記多次元表が用途情報を格納するのに使用されている、請求項２６に記載のプログラム記憶装置。
- 前記用途情報がデータウェアハウス用のものである、請求項２７に記載のプログラム記憶装置。
- さらに、
前記多次元表のための複合次元索引を作成するステップを備えた、請求項２６に記載のプログラム記憶装置。 - 前記複合次元索引を作成するステップを自動的に実行する、請求項２９に記載のプログラム記憶装置。
- 前記複合次元索引が複合キーのリストを備え、
各複合キーが前記多次元表のセルに関連付けられているとともに、前記セルのために少なくとも１つのブロックＩＤのリストを備えている、請求項２９に記載のプログラム記憶装置。 - さらに、
前記表に格納された情報を求める照会を処理するステップを備えた、請求項２２に記載のプログラム記憶装置。 - 前記照会を処理するステップが、
前記少なくとも１つのブロック索引および複合次元索引のうちの一方の情報を用いてブロックＩＤのリストを取得するステップと、
少なくとも１つのブロックをスキャンして少なくとも１つの基準を満たすレコードを探し出すステップであって、その際に前記ブロックＩＤのリストを用いてスキャンすべき前記少なくとも１つのブロックを探し出す、ステップを備えた、請求項３２に記載のプログラム記憶装置。 - 前記照会を処理するステップが、
前記表の全体をスキャンして少なくとも１つの基準を満たすレコードを探し出すステップ、および、
レコード基準索引を用いて少なくとも１つの基準を満たすレコードを探し出すステップの少なくとも一方を備えた、請求項３２に記載のプログラム記憶装置。 - 前記照会を処理するステップが、
索引ＡＮＤを備えている、請求項３２に記載のプログラム記憶装置。 - 前記照会を処理するステップが、
索引ＯＲを備えている、請求項３２に記載のプログラム記憶装置。 - 前記照会を処理するステップが、
コスト・モデルに基づいて照会計画を作成するステップと、
前記照会計画に従って前記照会を処理するステップとを備えている、請求項３２に記載のプログラム記憶装置。 - さらに、
保守要求を処理するステップを備えた、請求項２２に記載のプログラム記憶装置。 - 前記保守要求が、
ロード、再編成、挿入、削除、パージ、および更新のうちの１つを求める要求から成る、請求項３８に記載のプログラム記憶装置。 - 前記表のクラスタリングが、前記保守要求を処理したあとも維持されている、請求項３８に記載のプログラム記憶装置。
- ロードまたは挿入を求める保守要求を処理する前記ステップが、
空のスペースが存在する場合に前記少なくとも１つのブロックのうちの１つを使用するステップ、および、
空のスペースが存在しない場合に前記表に新たなブロックを割り当てるステップのうちの一方を備えている、請求項３９に記載のプログラム記憶装置。 - 再編成、削除、またはパージを求める保守要求を処理する前記ステップが、
スペースを再利用するステップを備えている、請求項３８に記載のプログラム記憶装置。
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 JP2003330964A (ja) | 2003-11-21 |
| JP3945771B2 true 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) |
Families Citing this family (80)
| 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 |
| 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 |
| US8302073B2 (en) * | 2006-06-15 | 2012-10-30 | International Business Machines Corporation | Moving and copying dependencies along with source code |
| 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 |
| US8145582B2 (en) * | 2006-10-03 | 2012-03-27 | International Business Machines Corporation | Synthetic events for real time patient analysis |
| 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 |
| 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 |
| CA2680217C (en) * | 2007-03-06 | 2017-06-13 | Nitrosecurity, Inc. | A database system with database indexes for improved performance |
| US8484220B2 (en) * | 2007-03-06 | 2013-07-09 | Mcafee, Inc. | Clustered index with differentiated subfields |
| 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 |
| US8793444B2 (en) | 2011-05-05 | 2014-07-29 | International Business Machines Corporation | Managing large page memory pools |
| US8656133B2 (en) | 2011-05-05 | 2014-02-18 | International Business Machines Corporation | Managing storage extents and the obtaining of storage blocks within the extents |
| US8799611B2 (en) | 2011-05-05 | 2014-08-05 | International Business Machines Corporation | Managing allocation of memory pages |
| US8683169B2 (en) | 2011-05-05 | 2014-03-25 | International Business Machines Corporation | Selecting an auxiliary storage medium for writing data of real storage pages |
| 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 |
| 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 |
| US9514187B2 (en) | 2012-09-28 | 2016-12-06 | Oracle International Corporation | Techniques for using zone map information for post index access pruning |
| 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 |
| US10642837B2 (en) | 2013-03-15 | 2020-05-05 | Oracle International Corporation | Relocating derived cache during data rebalance to maintain application performance |
| US9256633B2 (en) | 2013-03-15 | 2016-02-09 | International Business Machines Corporation | Partitioning data for parallel processing |
| 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 |
| JP6192781B1 (ja) * | 2016-07-26 | 2017-09-06 | 三菱電機株式会社 | データ管理プログラム及びデータ管理装置 |
| 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 |
| WO2020018718A1 (en) | 2018-07-17 | 2020-01-23 | 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 |
| WO2002003251A2 (en) * | 2000-06-29 | 2002-01-10 | Alphablox 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
Also Published As
| Publication number | Publication date |
|---|---|
| US7080081B2 (en) | 2006-07-18 |
| US20030195898A1 (en) | 2003-10-16 |
| JP2003330964A (ja) | 2003-11-21 |
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 | |
| EP1629406B1 (en) | Limiting scans of loosely ordered and/or grouped relations using nearly ordered maps | |
| US6629102B1 (en) | Efficiently updating a key table during outline restructure of a multi-dimensional database | |
| US6374232B1 (en) | Method and mechanism for retrieving values from a database | |
| US6334125B1 (en) | Method and apparatus for loading data into a cube forest data structure | |
| 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 | |
| JP2583010B2 (ja) | 多層インデックス構造におけるローカルインデックステーブル及び大域インデックステーブルの間の一貫性を維持する方法 | |
| US6665682B1 (en) | Performance of table insertion by using multiple tables or multiple threads | |
| US7158996B2 (en) | Method, system, and program for managing database operations with respect to a database table | |
| US6424967B1 (en) | Method and apparatus for querying a cube forest data structure | |
| US6470344B1 (en) | Buffering a hierarchical index of multi-dimensional data | |
| US9672241B2 (en) | Representing an outlier value in a non-nullable column as null in metadata | |
| US20120323971A1 (en) | Optimizing data storage and access of an in-memory database | |
| US6480848B1 (en) | Extension of data definition language (DDL) capabilities for relational databases for applications issuing DML and DDL statements | |
| EP2020637B1 (en) | Method and system for fast deletion of database information | |
| Padmanabhan et al. | Multi-dimensional clustering: A new data layout scheme in db2 | |
| US20050076018A1 (en) | Sorting result buffer | |
| US20230103328A1 (en) | Data compression techniques | |
| Joshi et al. | Materialized sample views for database approximation | |
| US6925463B2 (en) | Method and system for query processing by combining indexes of multilevel granularity or composition | |
| Kvet et al. | Master index access as a data tuple and block locator | |
| Johnson et al. | Hierarchically split cube forests for decision support: description and tuned design | |
| US6453322B1 (en) | Extension of data definition language (DDL) capabilities for relational databases for applications issuing multiple units of work |
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 |