(57)【特許請求の範囲】
【請求項１】
非ピボット化入力関係型データベーステーブルからピボット化出力テーブルにデータを変換する方法であって、
データ値項目を含む項目の行及び列を有するとともに、前記データ値項目から独立して且つ前記データ値項目のフォーマットとは異なるフォーマットで記憶された列名を含む項目を有する前記非ピボット化入力関係型データベースの入力テーブルを処理するための関係型データベース管理システム内で、異なる全テーブルフォーマットに変換したり異なる全テーブルフォーマットから変換することなく、
ピボット列を識別するために、前記入力テーブルの第１の列の前記データ値項目から独立して記憶された列の名前を選択するステップと、
値列を識別するために、前記入力テーブルの第２の列の前記データ値項目から独立して記憶された列の名前を選択するステップと、
前記ピボット列内にデータ値として記憶された一組の項目のそれぞれを、前記出力テーブル内のピボット化された列を表す前記出力テーブル内の列名項目として記憶された項目に直接に変換するステップと、
前記値列内にデータ値として記憶された項目を、前記出力テーブルのピボット化された対応する各列内の各データ値項目に置くステップと、及び
前記出力テーブルを、異なるフォーマットに又は異なるフォーマットから変換することなく、前記データベース管理システム内に直接に記憶するステップと、
を含む全ステップが実行されることを特徴とする方法。
【請求項２】
前記置くステップが、前記ピボット列内の前記データ値項目のセットの特定の１つとしての前記入力テーブルの同じ行内に位置する前記値列内の各データ値項目に対して、前記特定の１つのデータ値項目を、前記ピボット化出力テーブルの前記ピボット化された列の、前記ピボット列内の前記特定の１つのデータ値項目に対応する名前を持つ特定の１つに置くステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
ピボットリストとして、前記ピボット列内の前記データ値項目のセットの特定のものを選択するステップを更に含み、前記変換するステップが、前記ピボットリスト内のこれらのデータ値項目のみを、前記列名項目に変換することを特徴とする請求項１に記載の方法。
【請求項４】
前記変換するステップが、前記ピボット列内のＮＵＬＬデータ値項目を持つ前記入力テーブル内の行を変換しないことを特徴とする請求項３に記載の方法。
【請求項５】
前記入力テーブルが、前記ピボット列及び値列以外の少なくとも１つの列を有することを特徴とする請求項１に記載の方法。
【請求項６】
前記少なくとも１つの列内のデータ値項目の等しい値によって前記出力テーブルの行をグルーピングすることを特徴とする請求項５に記載の方法。
【請求項７】
非ピボット化入力関係型データベーステーブルからピボット化出力テーブルにデータを変換する方法を、好適にプログラムされたコンピュータに実行させるようにするための命令表現を記録する媒体であって、
データ値項目を含む項目の行及び列を有するとともに、前記データ値項目から独立して且つ前記データ値項目のフォーマットとは異なるフォーマットで記憶された列名を含む項目を有する非ピボット化入力関係型データベースの入力テーブルを処理するための関係型データベース管理システム内で、異なる全テーブルフォーマットに変換したり異なる全テーブルフォーマットから変換することなく、
ピボット列を識別するために、前記入力テーブルの第１の列の前記データ値項目から独立して記憶された列の名前を選択するステップと、
値列を識別するために、前記入力テーブルの第２の列の前記データ値項目から独立して記憶された列の名前を選択するステップと、
前記ピボット列内にデータ値として記憶された一組の項目のそれぞれを、前記出力テーブル内のピボット化された列を表す前記出力テーブル内の列名項目として記憶された項目に直接に変換するステップと、
前記値列内にデータ値として記憶された項目を、前記出力テーブルのピボット化された対応する各列内の各データ値項目に置くステップと、及び
前記出力テーブルを、異なるフォーマットに又は異なるフォーマットから変換することなく、前記データベース管理システム内に直接に記憶するステップと、
を含む全ステップを実行するようにしたことを特徴とする媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子データ処理に係り、特に、関係型データベースにおけるテーブル処理及びそれに類する形式のデータ管理ソフトウェアのための新しいクエリ演算に関する。
【０００２】
【従来の技術】
（発明の背景）
データベースとは、編成構造化されたデータの集合体である。通常のデータベースは、文字列、数値、他の場所に置かれたデータに対するポインタ等の特定種類のデータ項目を含む多数のフィールドを有するレコードのセットとしてコンピュータに記憶されている。関係型データベースには、任意の数の矩形のテーブルが含まれている。各テーブルはレコードセットを持ち、各レコードはそのテーブルの行（row）と呼ばれる。同じテーブル内にある各レコードは、それぞれ同じ数のフィールドを持っている。（しかし、レコードのいくつかのフィールドにはデータが含まれておらず、このデータを持たないフィールドは、NULL値を持っていると言われる。）テーブルのフィールドは、名前で指定することができる列（column）のセットから構成されているが、この名前はデータそれ自身の一部ではない。レコードは、それらを個々に識別する外面的特徴を持っていない。その代わり、これらデータには、いくつかのフィールドの組合せの内容から成るキーを使ってアクセスされる。つまり、関係型データベースは、ソフトウェアにより実行される連想メモリと考えることができる。
【０００３】
データベース管理システム（ＤＢＭＳ、或いはデータベースシステム）とは、データベースにおいてデータを記憶し維持し検索するためのコンピュータソフトウェアである。通常、ＤＢＭＳは、索引、ロギング、レコードロッキング等の、性能、信頼性、完全性を高める機能要素を備えている。また、ＤＢＭＳは、データベースから特定のデータを探し出すための、そしてこれらクエリを検索エンジンに与えるための、一つ又は複数のインターフェースを常備している。検索エンジンは、データベースを検索し、通常、その結果をクエリの仕様に合わせた関係テーブルの形でユーザーに伝える。
【０００４】
最も良く知られている関係型データベースのインターフェースは構造化クエリ言語（ＳＱＬ）である。このインターフェース言語には多くの変形があるが、米国規格協会（ＡＮＳＩ）や国際標準化機構（ＩＳＯ）により標準版が定義されている。
【０００５】
現在最も商業化されているＳＱＬは、これらの標準版に従ったものであるが、それらの多くは、標準で定義されたものに追加の構成を含んでおり、言換えると様々な標準準拠レベルで言語構築されている。
【０００６】
関係型データベースや関係型クエリ言語は、矩形テーブルのセットとしてデータを取扱う。しかし、多くのデータベースは、概念的には多次元であり、例えば時間｛日、月、年｝、場所｛店舗、市、州｝、カテゴリー｛製品、製品グループ｝、関係者｛社員、部、課｝、支払｛現金、小切手、クレジット｝等の軸に基づくものである。ユーザーは、多くの集合体から成る１つの集合体としてこのようなデータを考えることに有用性を見出すことが多く、これらデータを色々な観点から見たいと望んでいるかもしれない。上述した例において、１つの観点としては、各レコードが場所を提示し、その場所に関する毎月の売上データの集合体を含むようなレコードの集合体である場合で、他の観点は、各レコードが時刻を表し、各レコードの複数のフィールド（即ち、テーブルの列（column））が様々なカテゴリーについての売上数値を集合するような複数のレコード（即ち、テーブル行（row））の集合体が考えられる。
【０００７】
この視点から、データベースのテーブルをある観点から他の観点に変形する、即ちデータの次元を構成変更（回転）できるようにすれば、従来のＳＱＬのようなクエリ言語に更なる有益な能力が付加されることになる。この意味において、観点即ち次元を回転するということは、列セットとしてテーブルに表された次元を、行セットとして表された次元で置換えることを意味する。従来の関係型ＤＢＭＳ製品及び標準では、観点を回転するための直接的な演算を行うことはできない。これを間接的に行うようにＳＱＬクエリを作ることは可能であるが、このようなクエリは、大規模で複雑であり、またエラーが発生し易く処理速度も遅く、更に並列処理が可能な場合であっても効率的な実行計画に最適化するのは困難である。
【０００８】
一部の従来のスプレッドシートソフトウェアには、ユーザー選択の矩形のセル内のデータの置換えを、行列代数の「転置」演算において行列要素αijをαjiに移転させるのと同じ方法でユーザーが行えるものがある。例えば、マイクロソフト・エクセルのピボットテーブル機能では、ユーザーは、矩形のセルを選択してテンポラリー・クリップボードにコピーし、目標セルを指定してオプションメニューから「転置」を選択した後に「特殊な貼り付け」操作を行う。更に、ユーザーは、マイクロソフト・オフイス等の互換性のあるアプリケーションプログラム一式を使って、マイクロソフト・アクセスのデータベース構成要素であるデータベーステーブルからデータを選択し、そのデータを、矩形のスプレッドシート・セルのようなエクセル構成要素に対し単独オブジェクトとして転送してそのセルを転置し、次に、そのセルを転置フォーマットレコード集合体としてアクセスデータベースに転送し戻すこともできる。スプレッドシートにおけるピボット演算については、J. C. Nossiterの「ウインドウズのためのエクセル５の利用法」Ｑｕｅ社（１９９５年）及びB. Desmaraisの「高信頼アプリケーションのためのマイクロソフト・エクセル・ピボットテーブルの利用法」ＩＥＥＥ第３４回年報春季信頼性シンポジューム（１９９６年４月１８日）７９−８１頁に記載されている。
【０００９】
この方法によるデータ項目の転置は、下手なやり方でもあり機能的にも制限されたものである。小規模のデータベースであっても、１つのクエリを実行するためだけに他のアプリケーションプログラムを呼出すのは無駄が多い。大規模なデータベースに関しては、転置されたデータがメモリ内に残るという従来の要件により、この方法を行うことは不可能となっている。ホストベースの検索エンジンを使用したクライエント・サーバ・アーキテクチャに関しては、この演算を行うために、スプレッドシート・プログラムに接続する方法は存在しない。どのような環境下においても、スプレッドシートを介する転置には必ず手作業が伴うため、クエリの内的部分をデータベースプログラム内に構成する転置を行うことはできない。このような外部演算は、従来のデータベースのクエリプロセッサや他の検索エンジンにおける高性能の再公式化、再書込み、及び他の最適化手順に関与することはできない。より概念的レベルにおいては、スプレッドシートと関係型データベーステーブルとの基本的な差異によって、望ましい転置形式を採ることが妨げられている。例えば、データベーステーブルの列（column）又はフィールドの名前は、テーブルそれ自体の一部ではない。つまり、スプレッドシートにおける列（column）の見出しがスプレッドシート内ではセルの行（row）であるというようには、それらデータベーステーブルのフィールドの名前は、テーブルのレコードにはならない。このように、スプレッドシートの行（row）がテーブルのレコードとしてデータベースプログラムに戻される場合、スプレッドシートの矩形のセルを転置することにより、セルの列（column）を列（column）の名前に変換することはできない。
一部の非関係データベースシステムには、スプレッドシート・ピボット演算と類似した演算を持っているものがある。ＯＬＡＰ（オンライン分析処理）は、U. Flohrの「ウェブによるＯＬＡＰ」ＢＹＴＥ、１９９７年９月、８１−８４頁；E. Lindholm他の「データメーションの機能概要：ＯＬＡＰサーバ」ＤＡＴＡＭＡＴＩＯＮ、１９８５年５月、７０−７１頁；M. Frankの「ＢｒｉｏＱｕｅｒｙ３．５」ＤＢＭＳ  ＯＮＬＩＮＥ、１９９６年２月；「ＯＬＡＰ及びＯＬＡＰサーバ定義」（ＯＬＡＰ委員会、１９９５年）；及びC. B. Darlingの「ＯＬＡＰＢＯＸ考」ＤＡＴＡＭＡＴＩＯＮ、１９９６年４月１５日、８８−９２頁に言及されているように、多次元「立方体」データに関する回転演算を実行することができる。
【００１０】
マイクロソフトＳＱＬサーバの実行エンジンは、項目更新ストリーム内に(row_identifier, old_values, new_values)という書式を持つテーブル更新の各項目を、特定の行値及び列値を転置する「項目削除」と「項目挿入」とに分離するための厳密に内部的な演算、及び「項目削除」と「項目挿入」とを「項目更新」にたたみ込むための類似した演算を行う。これらの演算は、ユーザーが利用出来るものではなく、更にユーザークエリに関与することもできない。つまり、クエリプロセッサは、データベースを更新している間に実行される特定機能の効率的実行を促進するためだけに内部的にこれらを利用しているに過ぎない。
【００１１】
従って、特に関係型データベースに対し、観点を迅速且つ効率的に回転する機能を付与することにより、データベース技術は飛躍的に拡充される可能性がある。更に、回転即ち転置の演算に対して、その意味及び構文が自然な拡張としてＳＱＬ等のクエリ言語にうまく組込まれ、従来の構造のデータベースクエリ・プロセッサや他の検索エンジンでも、複雑或いは特異な設備を必要とせずに、最適化され実行することができるようにするというニーズも存在する。
【００１２】
【課題を解決するための手段】
（発明の要約）
本発明は、テーブルのデータ項目に異なる観点を提供するために、その項目が関係型データベースに定義されているテーブルの行（レコード）と列（フィールド）とを変換する「ピボット」演算を提供する。本演算は、入力テーブルとピボット仕様とを受取り、出力テーブルを作り出す。本演算は、従来のデータベースクエリプロセッサ、検索エンジン、及びサーバに簡単に組込まれるような方法によりインターフェース言語構成内で実行される。本演算は、複数のフィールドそれら自身の名前として1つ又はそれ以上の指定されたテーブルの列（column）の値を使用して、特定されたテーブルの複数のレコードの複数のフィールド内のデータを、異なる複数のレコードの同じフィールド内に置換える。これ以外の列（column）のデータは、ピボット化されたテーブルのデータ値によりグループ化される。
【００１３】
最終的な結果が元の観点を持つような場合であっても、データベーステーブルにおいて他の観点から他の関係演算を実行する方がより簡単な場合がある。従って、本発明は、ピボット機能の逆機能としての「逆ピボット」演算も提供する。また、記憶されたテーブル即ち中間的結果を逆ピボット化することが望ましい場合もある。
【００１４】
これらの演算は、これら演算をデータベースクエリに組込む簡易で直感的な方法に加えて、クエリの書法を簡素化するとともに、よりエラーの起こりにくいものとする。例えば、これらの演算は、テーブルをこれら演算自体に結び付ける必要性を減らす、若しくは皆無とする。本演算を行う方法によれば、簡単で有効な構文拡張と明確に定義された意味とを持った状態で、深くネスティングされた複数の演算を行うことが可能となり、良く知られているプログラム言語パラダイムが用いられる。クエリにおけるメソッド引数としてテキストの使用を可能とすることにより、拡張されたＳＱＬ言語をより有効且つ簡単に使用することができる。更に、この方法で使用することができる関係代数式のセットを非手続き型のクエリ式に拡張することは、「sample」、「top」、「rank」等の他の演算にも適用することができる。
【００１５】
本発明によるピボット及び逆ピボット演算は、特に関係型データベースを含む各種データ操作ソフトウェアやシステムアーキテクチャと本質的に互換性を持っている。これら演算は、言語レベル（例えば、ＳＱＬや他のクエリ言語に対する直感的拡張を用いることによる）、及び処理レベル（例えば、クエリ最適化やクエリ実行）のいずれにおいても上記したシステムに組込むことができる。
【００１６】
複数のデータソースが相互に異なる形、つまり異なる行／列の比を有する場合、複数のデータベースから単一のデータウェアハウス・データベースにデータを組込むと、「インピーダンス不適合」の問題に直面することが多い。殆ど当然に、このようなデータベースは、相当大規模なものとなる可能性がある。このようなデータを正規化することは、状況次第である。つまり、ピボット化されたフォーム即ち観点にデータを記憶することは、１つのスキーマにとっては最適（つまり、まさに必要）であるかもしれないが、他のスキーマは、逆ピボットフォームを選択即ち必要とするかもしれない。従って、ピボット及び逆ピボット演算を追加することは、異なるソースからのデータ、特に多量のデータの組合せにとって大きなメリットとなる。
【００１７】
また、本発明によって提供される新しい演算は、低レベルのＤＢＭＳ処理を、例えシステムリソースが限られた状態であっても促進する。この新演算の拡張可能な構文及び明確な意味により、特により効率的な実行のためにクエリを書換える場合において、複雑なクエリの自動的な生成と最適化が促進される。これにより、索引の更新処理、完全性の保守管理等の純粋に内部的なＤＢＭＳ機能も恩恵を受ける。また、「IN」、「OR」、及び「UNION」等のクエリを含むＳＱＬクエリの処理を改善することができる。「GROUP BY」クエリ用に既に使用されている多くの最適化技術は、ピボットや逆ピボットクエリを処理するために通常どおり使用することができる。これらクエリのための並列処理技術を含む従来の実行アルゴリズムは、ソートされておらず且つ区分化されているテーブルや結果を含むピボット化されたテーブル即ちクエリ結果に適用される。
【００１８】
本発明の他の特徴や利点及び本発明の範囲内にある変形例は、以下の詳細な説明により当業者に示されるであろう。
【００１９】
【発明の実施の形態】
（発明を実施するための最良の形態）
模範的な動作環境
データベース管理システムは、独立型パーソナル・コンピュータ、ミッドレンジ及びメインフレーム・コンピュータ、ピアトゥピア（peer-to-peer）並びにクライアント／サーバ・ネットワーク、及び多くのアーキテクチャの広域分散型システムを含む、多くの異なる種類のデータ処理システムにおいて実行される。すべてのデータ処理システムは、本発明に適した環境である。しかしながら、説明の目的で、本発明は図１に記載された従来のクライアント／サーバ・コンピュータ・システム１００に関連して説明される。ネットワーク配線１１０は、多くのパーソナル・コンピュータ（ＰＣ）１２０を、ネットワーク・アダプタ１２１及び１３１を介してサーバ１３０に相互接続する。サーバ１３０は、大量のデータを通常の企業データベースに維持するための記憶サブシステム１３２を含む。他のシステム・アーキテクチャもまた、本発明に適した環境である。例えば、装置１２０は、メインフレーム又はミッドレンジコンピュータ１３０に接続されたターミナルでもよいし、又は装置１３０それ自身が、ピアトゥピア・ネットワークで複数のＰＣ１２０に接続されたＰＣから成っていてもよい。小型でささやかなデータベースに対しては、システム１００全体が、クライアント及びサーバの両方として動作する単一のＰＣから成っていてもよい。同様に、ファイル記憶装置は、多くの異なるマシンの間で分散されてもよい。図１は、クライアントへの分散されたダウンロードのためのクライアント及びサーバ・ソフトウェアを記憶してもよい外部記憶媒体１３３、及びデータベース・テーブルのオフライン記憶のための、ディスケット等の他の媒体１３４を図示したものである。
【００２０】
図１及び以下の検討は、パーソナル・コンピュータ１２０の簡潔な、一般的な説明を提供することを意図する。要求はされないが、本発明は、例えばプログラム・モジュール等の、パーソナル・コンピュータで実行されるコンピュータ実行可能命令の一般的な文脈で説明されるであろう。一般的に、プログラム・モジュールは、特定のタスクを実行し又は特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに当業者は、本発明が、ハンドヘルド機器、マルチプロセッサ・システム、マイクロ・プロセッサ−ベース又はプログラム可能民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む、他のコンピュータ・システム構成で実装されてもよいことを認識するであろう。本発明はまた、タスクが、通信ネットワークを通してリンクされたリモート処理装置によって実行される、分散型計算環境において実施されてもよい。分散型計算環境において、プログラム・モジュールは、ローカル及び遠隔両方の記憶装置に配置されてもよい。
【００２１】
図２は、図１に記載のシステム１００において動作することができる一般的な従来のクライアント／サーバ・データベース管理システム２００のブロック図である。クライアント・アプリケーション・プログラム（ＣＬ．ＡＰＰＬ）２１０は、マイクロソフト・ウィンドウズ９５等のＰＣオペレーティング・システム（ＯＳ）２２０の下で、各ＰＣの中で実行される。他の機能の中でも特に、クライアント・アプリケーション２１０は、ＰＣ１２０におけるユーザからのデータベース照会（クエリ）を受け付けるための機能（Ｑ）２１１を含む。ユーザ・エントリに加えて、ＰＣ１２０のいくつかにおいて実行されている他のアプリケーション・プログラム（ＡＰＰ）２３０は、予め定義されたホスト言語のアプリケーション−プログラム・インターフェース（ＡＰＩ）２３１を介して、ＤＢＭＳクライアント２１０へのクエリを提示してもよい。
【００２２】
サーバ１３０の中で、例えばマイクロソフトＳＱＬサーバ等のＤＢＭＳサーバ・アプリケーション２４０は、例えばマクロソフト・ウィンドウズＮＴ等のサーバ・オペレーティング・システム２５０の下で実行される。ＤＢＭＳプログラム２４０は、データベース２６０によって例示された、多くの関係データベースを生成し、照会（クエリ）し、保守し及び修正するためのサービスを提供する。プログラム２４０は、オペレーティング・システム２５０のファイル−システム・サービス（file-system service）２５１を採用してもよく、又は独自のファイル・システムを提供してもよい。オペレーティング・システム２５０は、クライアント２１０からの各要求に対して、ＤＢＭＳアプリケーション全体の個別のインスタンス（instance）を実行することができる。しかしながら、より高い効率のために、プログラム２４０は、各クライアント接続に、ＤＢＭＳカーネル（kernel）において個別のスレッド（thread）２４２を付与する。さらに、このスレッドは、ネイティブのオペレーティング−システム・スレッドでもよく、メモリ保護処理、記憶装置へのより良いアクセス等のためのすべてのウィンドウズＮＴ機構を伴う。検索エンジン（search engine）２４１は、以下でより完全に説明されるとおり、データベース２６０のテーブル２６１上で、個々のクライアント２１０からのクエリ及び他の要求を処理する。それはまた、レコードロック（record locking）、アトミック・トランザクション（atomic transaction）等のための従来の機能で、データベースの完全性を実現する。マイクロソフトＳＱＬサーバにおいて、クエリ機能２１１と検索エンジン２４１との間のインターフェース言語は、トランザクトＳＱＬ（Transact-SQL）であり、それは標準ＡＮＳＩ  ＳＱＬ８９及びＡＮＳＩ  ＳＱＬ９２言語の機能のほとんどと、さらにより高い柔軟性及びプログラム可能性を供給するための拡張機能を提供する。
【００２３】
図３は、前記クライアント・アプリケーション２１０のいずれかから転送されたクエリを処理するための、図２に記載された検索エンジン２４１のいくつかの従来の機能３００を示す。ＳＱＬクエリは、結果を得るための一連のステップと言うよりむしろ、所望の結果の属性又は述語の仕様であるので、ＳＱＬは非手続き言語である。すなわち、SELECT year, quarter, sales FROM Narrow WHERE sales < (SELECT AVG(sales) FROM Narrow) ORDER BY year, quarter 等のクエリは、出力テーブルの属性を特定する。前記出力テーブルの列（column）は、Narrowと名づけられた入力テーブルから引き出されたyear, quarter, 及び salesと名づけられた列（column）に対応する。前記出力−テーブル行（row）（レコード）は、yearで、それから各 yearの値の中の quarterで並べられ（すなわちソートされ）る。前記出力に現れる前記入力テーブルからのレコードは、salesの値が、Narrowと名づけられたテーブルにおける salesのすべての値の平均値よりも小さい場合のものだけである。SELECT AVG(sales) FROM Narrowという入れ子型サブクエリ（nested subquery）は、Narrowテーブルにおける売上の平均値を含む単一の列（column）及び単一の行（row）のみを有するテーブルを生成する。前記入力テーブルのレコードがアクセスされる方法並びに順番、及び前記出力テーブルを作成するための手続き即ちプラン（plan）の他の詳細は、クエリそれ自身によっては定義されない。
【００２４】
検索エンジン２４１はクエリを受け取ると、ステップ３１０に記載のとおり、前記クエリを内部又はトークン化された（tokenized）形式に解析する。検証（validation）ステップ３２０は、クエリにおいて名づけられたデータが実際にデータベースに存在することを保証し、データと完全性制約を調べる。それは、前記クエリのある部分、例えば３２１においてマクロ（macro）やビュー（view）を拡張してもよい。出力３２２は、あらゆるエラーを、ユーザ又はクエリの他のソースに報告する。最も制限された検索エンジンを除くすべては、ステップ３３０に記載のとおり、クエリに広範囲な最適化を実行する。最適化は、クエリの部分を結合し又は分割し、演算及びサブクエリ等を再編成し、及び記憶されたデータベース・テーブルのレコードへのアクセスの順番を整理し及び機能を修正する等の他の方法によって、前記クエリを書き換えることを含んでもよい。各実行戦略候補（candidate execution strategy）に対して、それらは、この戦略を使用して前記クエリを実行するために必要となる演算時間やリソースを表すコスト値を計算し、その後すべての可能性のある候補の中から一つの戦略を選択する。これらの最適化プログラム（optimizer）を設計する技術は複雑であり難解であるが、熟練した当業者は、様々な種類の新しいクエリ機能を含むように、従来の最適化プログラムを適応させる能力を有し、他のより手続き的な言語に対する翻訳プログラムの設計者もまた、この同じ一般的なクラスの最適化プログラムを日常的に構築する。M. Jarke及び J. Kochの調査論文、「データベース・システムにおけるクエリ最適化」、ＡＣＭコンピューティング・サーベイ（ACM Computing Survey）１６，２（１９８４年６月），１１１ページでは、データベースクエリ最適化プログラムの構造がより詳細に議論されている。
【００２５】
前記ステップ３３０の出力は、前記クエリに回答するためのクエリ評価プラン（又は単に「プラン」）である。ステップ３４０はこのプランを、通常は従来の関数ツリーとして表現される、手続き的形式にコンパイルする。次にステップ３５０は、データベース・オブジェクト（database objects）に対するプランを実行するための、単純なツリー走査アルゴリズム（tree-traversal algorithm）をランさせてもよい。ステップ３５０の出力は、前記クエリのソースに戻される出力テーブルの形式の、前記クエリの結果である。ここに記載された一つ以外の検索エンジンは、個別のステップ３００を結合し又は分割してもよく、又はステップを省略し又は追加してもよい。G. Graefeの他の調査論文、「大規模データベースのためのクエリ評価技術」ＡＣＭコンピューティング・サーベイ２５，２（１９９３年６月），７３ページは、参照のためにここに組み込まれており、クエリの実行の問題を扱い、及び追加の説明及び議論を提供する数多くの参照を引用している。また、最新の検索エンジンの段階は、新しい構文、新しいクエリ機能、最適化知識及び実行技術に適応するための容易な拡張性のために特定的に設計されている。
【００２６】
ピボット及び逆ピボット演算
図４は、本発明に従ったピボット演算の構造を示す。この演算は、関係代数のレベルでのＳＱＬ演算の階層に適合する。関係データベース・システム及びインターフェースを設計する人は、クエリ処理を３つのレベルに分割する。関係の数学的理論は、この種類のデータベースに対する概念的フレームワークを供給するので、第一及び第二のレベルはしばしば、関係計算及び関係代数と称される。
【００２７】
関係計算は、あらゆる計算法と同様に、結果を得るためのあらゆる演算、手続き又は他の方法に名前を付けることなく、所望の結果の高いレベルでの記述又は仕様を扱う。すなわち、それはデータベースにおける現存の関係について、所望の結果の関係（テーブル）の定義を単に表現する。例えばSELECT employee.name, department.name FROM employee, department WHERE employee.dept_id = department.dept_idというクエリは、結果の関係の典型的なメンバ及び前記結果のメンバの属性の定義を表す限定によって、一つ以上の入力テーブルに関して、出力テーブルの属性及び制約を記述する。関係計算は、データベース、テーブル（「関係」）、及びクエリの正式で、正確な理解のための根拠を提供し、現在はＡＮＳＩ／ＩＳＯ標準であるデータベース言語ＳＱＬのクエリコンポーネントにおける商業的実現を見た。ＳＱＬがデータ管理製品で果たす重要な役割を考慮すれば、現実世界のためにデータベース機能を拡張することは、追加されたあらゆる機能が、ＳＱＬ言語の構文的及び意味的に明確な拡張になることを要求する。
【００２８】
関係代数は、より演算指向（ではあるが同等）の関係計算である。関係代数における演算又は関数は、一つ以上の入力テーブルを使用し、規則にしたがって出力テーブルを生成する。例えば、JOIN [employee.dept_id = department.dept_id] (employee, department)という関係演算は、両方のテーブルにおける dept_idと名づけられた共通の列（column）又はフィールドに沿って、employee及び departmentと名づけられたテーブルを結合する。（これは、例えば、「４＋５」という演算が「９」を生成する、２つの数を使用し第３の数を生成する加法のような演算に類似している。）関係代数の重要な特性は（１）演算は、同じ種類のオブジェクト、すなわち関係を使用しかつ生成する、（２）演算は、任意で複雑な構造に入れ子することができる、及び（３）新しい演算が追加できることである。関係代数において、入力オブジェクトは、入力を有するだけではなく、追加の情報を表すタグを備えていてもよい。上述の例においては、JOINという演算は、２つの関係代数式、すなわち結合されるべき２つのテーブル（employee, department）を特定するだけでなく、各テーブルにおける特定の列（column）の等しい値[employee.dept_id = department.dept_id]に沿って、のようなそれらがどのように結合されるべきかを特定する「結合述語」を指定する。
【００２９】
いくつかの大変有用なクエリ演算は、関係計算レベルで表現することは困難であるが、それらは簡単に及び簡潔に関係代数レベルに統合することができる。例えば、OUTER JOINは関係 JOIN演算の変形であり、単純な SELECT...FROM...WHEREというクエリ構文には容易に又は明確には適合しない。そのために、ＡＮＳＩ／ＩＳＯは、例えばSELECT employee.name department.name FROM employee LEFT OUTER JOIN deparment ON employee.dept_id = deparmtent.dept_idのようなFROM節において、テーブルに代わる一組の制限された関係代数式を許可する。すなわち、関係代数式で関係計算型クエリを拡張するための先例があるが、そのような拡張は、JOIN演算の変形にかなり制限されてきた。関係代数演算はしばしば、図３に記載されたブロック３３０におけるとおり、選択（selection）、射影（projection）、集約（aggregation）及び関係計算レベルでの他の非手続き的仕様を有するクエリの最適化に関与する。
【００３０】
クエリ実行プランは、第三の及び最低レベルのクエリ処理を構成する。関係代数演算の入れ子は、実行の順番を示すが、中間結果を生成するための特定の命令のアルゴリズム又はセットは、より高いレベルよりもむしろ、実行プランのレベルで発生する。例えば、関係JOIN演算を実行するための３つの基本的方法、入れ子ループ（nested loops）、マージ結合（merge-join）及びハッシュ結合（hash-join）があり、各方法は多数の変形を有する。実行プランは、そのような選択肢からの選択を明確に示し、図３に記載のブロック３４０において、クエリ処理の最低レベルで公式化される。
【００３１】
関係クエリ処理は、大変正確かつ明確な構造的フレームワーク内で定義されるので、すべての３つのレベル、言語拡張、関係代数演算、及び実行プランで、あらゆる新しい機能を定義することが重要である。本発明は、ピボット及び逆ピボット機能を、言語の拡張として、ＳＱＬクエリにおいて明確に関与する新しい関係代数演算として提供するものとする。
【００３２】
有効なクエリ式である第一正規形での入力テーブル式のための、ピボット演算の正式な定義は、Table.PIVOT(<value_column> FOR <pivot_column> IN (<pivot_list>))であり、出力のピボットされたテーブルもまた、有効な第一正規形のテーブルである。最も外側の括弧の間のテキストは、ピボット演算の仕様を構成する。ピボット仕様における最初の２つの列（column）は、ピボット演算の入力テーブルにおける列（column）でなければならない。これらの列（column）は、ピボット演算の出力テーブルには現れない。その代わり、ピボット仕様の中のピボット・リスト（pivot list）における各値は、ピボット演算の出力テーブルにおける新しい列（column）を定義する。入力テーブルにおいては、ピボット・リストにおけるエレメントは、ピボット列（pivot column）における値として現れる。値列（value column）における対応する値は、出力テーブルでの新しい列（column）における値になる。「グルーピング列」と称される、ピボット仕様に含まれない入力テーブルにおけるすべての列（column）は、出力テーブルに引き継がれる。
【００３３】
図４に記載の例４００では、仕様４２０に従って入力テーブル４１０をピボットすることで、出力テーブル４３０を生成する。NARROWと名づけられた入力テーブル４１０において QUARTERと名づけられたピボット列４１１は、出力テーブル４３０において４つの列４３１、４３２、４３３、及び４３４になる。これらの列の名前は、SPRING、SUMMER、FALL、WINTER、という４つの個別の値であり、列４１１において値として現れ、また４２０においてはINというキーワードに続く値のリストにおいて現れる。値列４１２における売上（SALES）の数は、４つの列４３１乃至４３４のうちの対応するものにおける値として現れるが、同じ地域（REGION）及び年（YEAR）に対する売上（SALES）の数字が、同じ行（row）になるようにピボットされ即ち回転される。グルーピング列４１３乃至４１４は、出力４３０において列４３５乃至４３６として現れる。仕様４２０がGROUP BY REGION, YEARという形式のＳＱＬ節を含んでいたかのように、出力において、前記行（row）は、第一のグルーピング列４１３の等しい値によって、そして第二のグルーピング列４１４の等しい値によってグルーピングされる。この例においては、ピボット演算の効果は、データが見える見え方を修正することである。入力テーブル４１０は、主として企業の複数のNarrow regionに対する年間のデータ傾向を示す一方で、出力テーブル４３０は、四半期による季節的追跡を許可する。（関係テーブルにおける前記行（row）は、名前を有しないし、特定の順番もないことがここで思い出されるべきである。列（column）は名前を有し、ソートされる。すなわち、それらは、その名前がクエリにおいて現れる順番で表示される。）ピボット演算は、比較的多くの行（row）と及び比較的少ない列（column）を有する入力テーブルを、より少ない行（row）とより多い列（column）を有する結果物としてのテーブルに変換する。
【００３４】
出力テーブルにおける前記ピボットされた列（column）は、入力テーブルの値列におけるデータと同じデータの種類（numeric型、varchar型等）を有する。値列、ピボット列及びピボットされた列（column）は、計算された式よりもむしろ、簡潔なデータを含む。両方のテーブルにおける列（column）の順番は、ＡＮＳＩ  ＳＱＬにおけるように重要ではなく、列（column）は、位置によってではなく名前によってのみ参照され得る。テーブル４３０は、REGION及び YEARのグルーピング列の値によってソートされるように図示されているが、ピボット演算は、行（row）の特定のソートや順序付けは含まない。
【００３５】
上述のとおり、入力テーブルにおける行（row）は、その値がピボット・リストに現れなければ、出力には現れない。入力−テーブル行（row）は、同等の定義に関して、あらゆるグルーピング列の等しい値によってグルーピングされる。各グループの中では、入力テーブルの各行（row）は、ピボット列において互いに別個の値を有する。各グループは、一つの出力行という結果になる。対応する入力行を有しない出力列に対しては、値は、ＳＱＬで定義された特別な値、NULLである。
【００３６】
図５は、ピボット演算のための図２に記載の検索エンジン２４１の、図３に記載されたモジュール３００によって実行されるステップのフローチャート５００である。ブロック５１０は、図１に記載のクライアント・ターミナル１２０のユーザ、又はここに記載されたいくつかの他のソースからクエリを受け取る。ステップ５２０は、データベース２６０におけるどのテーブル２６１が、演算の入力テーブルとしての働きをするかを識別し又は選択する。ステップ５２１は、入力テーブルのどの列（column）がピボット列になるのかを識別し、ステップ５２２は、どのピボット列（column）の値がピボットに関与するかを、前記ピボット・リストから識別し、そしてステップ５２３は、前記入力のどの列（column）が値列であるかを選択する。ステップ５３０は、他のテーブル２６１として出力を構成する。ステップ５３１は、前記ピボット・リスト内の各データ項目値に対する個別のピボット化列を配置する。ステップ５３２は、もしあれば、前記グルーピング列を構成する。（前述のとおり、これらは、ピボット仕様において識別されなかった入力テーブルの任意の追加の列である。）ステップ５４０は、上述のように、前記値列のデータ−項目値を前記出力テーブルの行（row）に挿入するが、この一つの方法は、ステップ５４１で示されたように、転置（transposition）によるものである。この転置を表現するための他の方法は、前記値列における各データ項目が、ピボットされた列（column）の一つ、すなわち前記入力テーブルの前記ピボット列におけるデータ値と同じ名前を有する列（column）へ配置されることである。ステップ５５０は、出力−テーブル行（row）を、任意のグルーピング列の等しい値によってグルーピングする。最後に、ステップ５６０は、図２に記載のデータベース２６０に前記出力テーブルを記憶する。
【００３７】
逆ピボット演算は、ピボット演算の逆関数であり、<Table_expression | query_expression>.UNPIVOT (<value_column> FOR <pivot_column> IN (<column_list>)として形式的に定義される。用語の意味は、前記ピボット演算に対するものと同じである。同じ仕様を有するピボット及び逆ピボット演算を入力テーブルに適用することで、前記入力テーブルをその本来の状態に戻す。図４に記載の例において、前記逆ピボット演算４４０をピボットされたテーブル４３０に適用することで、テーブル４１０に戻し、SALES４１２及び QUARTER４１１と名づけられた２つの列（column）が、列（column）４３１乃至４３４に置き換わる。
他のデータベースシステムの演算は、M.Gyssens他の「クエリと再構築のパラダイムとしてのテーブル」、１９９６年ＡＣＭ  ＳＩＧＭＯＤ「データ管理」国際会議の議事録、モントリオール、ケベック、カナダ、１９９６年６月３−６日、９３−１０３頁に述べられているグルーピング（grouping）／分割（splitting）や合併（merging）／折りたたみ（collapsing）の対のような相互反転として考えることができる。ピボット/逆ピボットも同様に相互反転である。
【００３８】
入力テーブルにおける各行（row）に対して、前記逆ピボット演算は通常、一つのピボットされた列（column）毎に対して、出力テーブルの一つの行（row）を生成する。（しかしながら、ピボットされた列（column）におけるNULL値は、出力行を生成しない。）前記ピボット・リストにおけるすべての列（column）は、前記入力において同じデータタイプを有していなければならず、前記出力の値列におけるエントリは、このタイプを有することになる。テーブルの逆ピボットは、その行（row）の数を増加させ、及び列（column）の数を減少させる。再度、図４はグルーピング−列値によってソートされたテーブル４１０を示しているが、前記逆ピボット演算は、前記出力における行（row）のソートを意図しない。
【００３９】
図６は、逆ピボット演算のための、図２に記載された検索エンジン２４１の、図３に記載されたモジュール３００によって実行されるステップのフローチャート６００である。ステップ６１０は、前記逆ピボット演算及びその仕様を受け取る。逆ピボットは、ピボットの逆演算になるように、ピボットされたテーブルを正確にそのピボットされていない形式に戻すように定義されているので、逆ピボットの仕様は、ピボットのためのそれに相補的ではなく、むしろ図４に記載の４４０において示されたような、前記ピボットされたテーブルを第一の場所に生成した仕様のそれとまったく同じ形式を有する。再度、ステップ６１０は、前記演算をユーザクエリ又は他の任意のソースから受け取ってもよい。ステップ６２０は、逆ピボットされるべき２６１等のピボットされたテーブルを識別し又は選択する。このテーブルは、実際に以前の演算でピボットされている必要はないが、通常はされているであろう。すなわち、前記ピボット演算は通常、視点の最初の回転を達成するために使用され、逆ピボットは通常、テーブルを明確で単純な方法で、最初のピボットされていない形式に戻すためだけに使用される。ステップ６２１は、前記仕様のピボット・リストを使用して、どの列（column）が、回転され又は転置されるべきピボットされた列（column）であるかを識別する。ステップ６２２は、前記値列及び前記ピボット列の名前を識別する。（少なくとも、以前のピボットがこの情報を保存しているサイド・テーブル（side table）を保持していないかぎり）前記ピボットされたテーブル内のどこにも現れないので、これらの名前は前記仕様に含まれる。
【００４０】
ステップ６３０は、前記逆ピボット演算によって生成されるべきピボット・テーブルを構成する。ステップ６３１及び６３２は、ステップ６２２において供給される名前を使用して、前記ピボット・テーブルにおいてピボット列及び値列を形成する。ステップ６３３は、前記ピボット・テーブルにおいてグルーピング列を作成し、それは、ステップ６１０において受け取られる逆ピボット仕様に含まれない前記ピボットされたテーブルの列（column）の各々に対して一つである。ステップ６４０は、前記ピボットされたテーブルからデータ項目を、前のステップにおいて構成された前記逆ピボットされたテーブルに転置する。前記ピボットされた列（column）の名前は、異なる行（row）においてデータ項目になり、前記ピボットされた列（column）における前記データ項目は、最初の（ピボットされた）テーブルにおいて、それらが存在していたピボットされた列（column）の名前と同じピボット−列値をそれぞれ有する行（row）において、新しい値列に入る。ステップ６５０は、グルーピング−列（column）行（row）の等しい値によって行（row）をグルーピングする。ステップ６６０は、図２に記載のデータベース２６０に前記テーブルを記憶する。
【００４１】
前記ピボット、値及びピボットされた列（column）は、単純なデータであって、計算された値ではないので、相関変数は、ピボット及び逆ピボット演算の仕様の中では許可されない。これらの新しい演算は、どの相関変数が、前記演算が適用されるクエリ式において許可されるか、または相関関数が許可されるか否かについてまったく影響を与えない。ＡＮＳＩ  ＳＱＬが、ピボット又は逆ピボット演算が起こらないクエリ式のためのテーブル及び列エイリアス（alias）を定義することを許可するなら、ピボット／逆ピボット演算を含む前記クエリ式に対して前記エイリアスを定義することは容認されるが、前記演算を除く前記クエリ式に対しては容認されない。例えば、Table1 AS Table2 (col1, col2)が許可される場合、Table1.PIVOT (...) AS Table2 (col1, col2, ...)は容認されるが、Table1 AS Table2 (col1, col2).PIVOT (...)は容認されない。
【００４２】
前記ピボット及び逆ピボット演算は、図３に記載のブロック３３０において、あらゆる数の従来の最適化技術を使用し得る。これらの演算は関係代数レベルの一部であるので、代数クエリ最適化プログラムは、最適化技術を実現するために最も適切な手段であり得る。他の最適化フレームワークも同様に適用可能であり得る。
【００４３】
いくつかの追加の最適化技術は、新しい演算の特定の属性を使用し得る。明らかに、ピボット及び逆ピボット演算の隣り合う対は、互いに相殺し得るし、従ってクエリから削除し得る。最適化プログラムは、前記ピボットされた出力テーブルにおける前記グルーピング列が、機能的に前記ピボット及び値列を決定することを認識し、それゆえにその結果のテーブルの関係キーを形成する。（これは、従来のGROUP BY演算における前記グルーピング列に大変似ている。）逆ピボット出力テーブルにおいては、前記グルーピング列は前記ピボット列とともに、機能的に前記値列を決定する。これらの属性は、代替的な実行プランを比較するための選択的評価及びクエリ−コスト計算のための出力行の数を評価することに関して助けとなり得る。それらはまた、クエリの前記実行を単純化する書き換え規則を適用するための条件を生成する場合に便利であり得る。テーブルが縦に区切られている場合、完全な行（row）の再アセンブル及びそれに引き続く逆ピボットの演算は、両方の演算を排除して相殺してもよい。
【００４４】
前記ピボット演算のＳＱＬ  GROUP BY節に対する概念的類似性によって、前記節を有するクエリを最適化するための多くの技術及び規則は、新しい演算に対しても同様に機能することができる。典型例は（１）前記グルーピング入力の大きさを低減させるため、又はより効果的な結合（join）アルゴリズムを可能にするために、結合（join）の上にピボットをプルすること、（２）前記結合（join）入力を低減させるため又は前記ピボットのためのより効果的な実行プランを使用するために、結合（join）の下にピボットをプッシュすること、（３）二つの隣接するピボットをマージ（merge）して、おそらく効果的にそれらのうちの一つを排除すること、及び（４）ピボットを二つの部分に分割し、そのうち一つを、結合（join）を通して又は処理境界（process boundary）を横切って、並行実行環境におけるローカル／グローバル集約としてプッシュすること、を含む。一般的には、追加の列（column）を計算する式を含む、前記グルーピング列上のクエリの述部及び射影（projection）演算は、グルーピング演算と同じ方法で、ピボット／逆ピボット演算を（上又は下を）通って動くことができる。
【００４５】
一定のクエリ述部は、ピボットの結果のテーブルに対する述部（すなわち、条件）として取り扱われた時に、実行するのに効果的である、また表現するのにより簡単である。例えば、２つのピボットされた列（column）を互いに比較することは、表現するのに簡単であり、実行するのに効果的である一方、前記ピボット入力テーブルに適用される同じ述部は、複雑で、非効率的な入れ子クエリを必要とする。従って、演算のピボット／選択／逆ピボットのシーケンスを含めるための前記クエリの書き換えは、前記クエリを最適化するために使用され得る。例えば、図４に記載のテーブル４１０において、FALLにおける SALESが SPRINGにおける SALESを超えるテーブル行（row）を選択するためのクエリを検討する。ピボットされたテーブル４３０は、このクエリを、SPRING及び FALLの列（column）４３１及び４３３の間の比較として適応させ得る一方、本来のテーブル４１０は、前記比較を実行するために、前記テーブルをそれ自身に結合（join）することを要求する。図４に記載のテーブルを使用して、ピボット及び逆ピボット演算を（従来の複数行の形式で）含む大きなクエリは、
(SELECT * FROM
Narrow.PIVOT (Sales FOR Quarter IN (Spring, Summer, Fall, Winter))
WHERE Fall_Sales>Spring_Sales)
.UNPIVOT (Sales FOR Quarter IN (Spring, Summer, Fall, Winter))
でもよい。
【００４６】
図３に記載のブロック３４０に有用な実行プランは、当業者によって、グルーピング演算のための従来のプランから導くことができる。特に、ループ（looping）、索引付け（indexing）、ストリーム（streams）、ソート（sorting）、及びハッシング（hashing）に基づいたプランは、容易に思い浮かぶ。早期集約ソート及びハイブリッドハッシングは、有用な変形である。ピボット／逆ピボット演算は、共有メモリ、分散型メモリ、共有ディスク及びクラスタ・マシン等の並列アルゴリズムを含む、並列−実行環境に適応可能である。ローカル／グローバル集約はすでに、一つの可能性として述べた。
【００４７】
逆ピボット演算は、各入力レコードに対する複数の出力レコードを生成する単一の入力、単一の出力プランのみを必要とする。この演算は、共有メモリ、分散型メモリ、共有ディスク、及びクラスタ・マシン上で、簡単に並行して実行することができる。
【００４８】
変形及び拡張
上述の実施形態に対する多くの変形及び拡張は、単独でも互いに組み合わせても、いくつかの応用に有用であり得る。当然、最も明白であるのは、ドット呼び出し分離符号（dot invocation separator）等の表記規則の置換え又は増補、及びコンポーネントの再編成である。
前述のピボット／逆ピボット演算は、ピボットされたテーブル又は出力テーブルにおける列名に制限がある。標準ＳＱＬにおける列名は、スペースのない文字列でなければならない。列値はスペースを有するかもしれず、ピボットは値を名に変えるので、引用符付きの識別名及びリテラル（literals）を列名として使用するための方法を、簡単に案出することができる。同様に、文字列以外のデータタイプを有する列値を、列名に対する印刷可能な及び読み取り可能な表示として表示することは簡単であろう。名前の連結等、従来の名前操作は有用であろう。例えば、ピボット・リストは、ＳＱＬのASのようなキーワードを使用する列エイリアスを含み得る。（図４において、QUARTER値が季節名の代わりに「１」乃至「４」である場合、４２０の仕様は、(Sales FOR Quarter IN (1 AS “spring”, 2 AS “Summer”, 3 AS “Fall”, 4 AS “Winter”))と読める。）さらに、ASはあらゆる文脈においてピボット−結果列に再度名づけるために使用されてもよく、ユーザ定義機能は、複雑な列名を変換するため、又は名前をＳＱＬ実行の特定の制約に適合させるために供給され得る。
【００４９】
意味的拡張は、単一のステップでの複数列のピボット及び逆ピボットを含んでもよい。例えば、図４に記載の演算４５０は、３つの列４１１、４１２、及び４１４を、結果テーブル４３０の４つの列４３１乃至４３４の代わりに、８つの列（column）と入れ替える。すなわち、ピボット列の組は、すべてのピボット・リストのデカルト積又は外積を表す。前記ピボットされた列（column）に名前を付けるための規定は、Sales_1996_Springのように、名前を連結することを必要とするだけであり得る。同じ仕様での複数列逆ピボット演算は、この拡張に対する真の逆関数を提供するために、前記名前をそれらの本来の形式に復号することができる。さらなる拡張は、複数列（column）がステップ的にピボットすることを許可する。例えば、上述の８つの列（column）を生成するために、さらなるピボットを、列４３６についてすでにピボットされたテーブル４３０に適用することが望ましいであろう。テーブル４３０を逆ピボットして複数列（column）のピボットを適用するよりもむしろ、拡張された形式は、値列の代わりに列（column）のリストを許可する。例えば wide.PIVOT ((Spring, Summer, Fall, Winter) FOR Year IN (1996, 1997))。最適化プログラム３４０及びコンパイラ３５０は、これらの演算を、実行のための単一のプランへと簡単に折りたたむことができる。
【００５０】
前記ピボット演算（逆ピボットではない）は、ステップ５４０における前記値列に対して、MIN、SUM、AVG、さらに COUNT等の従来のＳＱＬ集約又はグルーピング機能をサポートすることができる。その場合、グループ当たりの単一の行（row）への制限は解除することができる。当然、新しい列（column）のタイプは、本来のそれとは異なるかもしれない。図４に基づいた以下の例は、集約（aggregation）を使用したクエリを示す：
(SELECT Year, Quarter, Sales FROM Narrow)
.PIVOT (SUM(Sales) FOR Quarter IN (Spring, Summer, Fall, Winter)
このクエリは、EAST及び WEST地域の SALESを、各YEARに対する企業全体を表す単一の合計へと統合する。グルーピング機能が許可されるバージョンにおいては、前記実装は、ピボット演算が、さもなければピボットされたテーブルの異なる行（row）における重複一次キーを生成するであろうすべての場合に、SUM等の特定の機能の暗黙アプリケーションを特定することができる。前記集約は情報の詳細を失うので、グルーピングを有するピボットは、逆転することはできないし、標準ＳＱＬでグルーピングされた出力は、同じ理由から逆転することができない。この拡張によって逆ピボットは真の逆関数として機能することができないが、実施形態は、すべての本来の値を保存する内部「サイド・テーブル」を加えることによって、この機能を維持する。
【００５１】
他の有力な拡張は、ピボット又は逆ピボット演算における、リテラル列名のリストを、SELECTクエリと置き換える能力を加える。より複雑な処理が、補助的クエリを最初にランさせ、それから前記補助的クエリの結果を使用して、ピボットされた列（column）のリストをバインドすることを必要とするであろう。すなわち、前記補助的クエリは、図３に記載のブロック３４０及び３５０におけるコンパイル及び実行を交互に要求する。前記実行は、ピボットされるべきクエリ式を計算することを、結果に対してクエリをランさせることと同様に要求する。
【００５２】
前記ピボット仕様は、ピボット・リストを完全に省略し、代わりにデフォルト（default）のクエリを提供する。例えば、クエリ４２０からIN (Spring, Summer, Fall, Winter)節を省略することで、SELECT DISTINCT Quarter FROM Narrowというデフォルトのクエリを代用することができる。これによって、クエリ４２０は入力テーブルを２回参照することになるので、Ｃ＋＋における「ｔｈｉｓ」という名前に類似して、演算の入力テーブルに対して専用の名前を導入すると便利である。そうすると演算４２０は次のようになる。
Narrow.PIVOT (Sales FOR SELECT DISTINCT Quarter FROM INPUT)。
【００５３】
ピボット・リストを要求する代わりに、前記逆ピボット演算は、演算の入力において、ピボットされた列（column）を除くすべての仕様を許可するであろう。上で修正された例４００において、逆関数演算は図４に記載の４４０のように、
Wide.UNPIVOT (Sles FOR Quarter IN (Spring, Summer, Fall, Winter))
か又は図４に記載の４６０のように、
Wide.UNPIVOT (Sales OVER (Region, Year))
と特定され得る。
この文脈でOVERをサポートすることは、前記入力テーブルから前記一組のピボットされた列（column）を決定することを必要とし、及び上述のとおり、補助的クエリを処理するための能力を要求する。IN及び OVER節は組み合わせることができ、一つ以上の列（column）がグルーピング列と同様にピボット列になることを許可する。これが本出願の視点から意味をなすであろう状況は、各々の次の四半期に対する、第一四半期以来の売上増加の計算を許すための、各出力行における春の売上の算入（inclusion）である。
【００５４】
いくつかのテーブルでは、一組の列（column）は事実上、直交又は独立になることができる。例えば、「都市（City）」及び「月（Month）」と名づけられた列（column）は、すべての月に対するすべての都市に対して、テーブル・エントリを有する傾向にある。他の列（column）の組は、階層的であり、例えば「州（State）」、「都市（City）」、及び「店舗（Store）」列（column）を有する「場所（Locations）」テーブル等、そしてそれらのデータはまばら（sparse）である。すなわち、ごく小数の都市が複数の州に現れるであろうし、及び複数の店舗を有する都市はほとんどないであろう。後者の場合において、２つのIN節を使用することは、ピボット演算において体裁を欠く構文及び意味になる。しかしながら、単一のピボット列の代わりにピボット列のリストを使用することで、この問題は改善される。ＡＮＳＩ  ＳＱＬの「行値」の概念が、この場合に適切である。常にではないが、通常は、クエリをリテラル列名のリストでなく、前記ピボット・リストとして特定する方が、より便利である。典型的な形式は、Locations.PIVOT (SalesVolume FOR (City, Store) IN (SELECT City, Store FROM (outlets)))であろう。
【００５５】
前記ピボット及び逆ピボット演算はまた、図３に記載のクエリプロセッサ３００の内部演算においても、有用であろう。さらに、参照一貫性の制約は、削除された候補キー及び新しい外部キーのためだけに強制される必要がある。ピボット／逆ピボット又は類似の回転を使用することは、同じキー値に関連する削除及び挿入項目を折りたたむことができ、従って潜在的に一貫性検査を冗長であるとして排除する。さらに、大変に大きいIN節を有する従来のクエリにおいては、検索エンジンによって暗示的に呼び出された内部逆ピボット演算は、列（column）として、多くのリテラル又はパラメータを含む単一の大変複雑な行（row）を、ループ（loops）、索引（index）、マージ（merge）及びハッシュ結合（hash join）等の従来の結合（join）方法、及びそれらの並行処理変形を使用して、データベース・テーブルに合わせることができる一組の行（row）にマッピングすることができる。ピボット／逆ピボット演算類似の内部呼び出しは、IN節としばしば同等である、OR及び UNIONクエリにおいて有用であり得る。
【００５６】
最後に、前記ピボット及び逆ピボット演算は、それらの拡張、最適化及び実行プランとともに、関係データベース・システムの分野外のデータベース管理システム及びデータ−操作ソフトウェアに含むことができる。例えば、代数を基礎とした統計的分析製品又は独立型ソーティングパッケージは、これらの新しい演算が、外部及び内部の両方で有用であることがわかるかもしれない。ＳＱＬ言語に関連して説明されたが、前記演算は必ずしもＳＱＬに統合され又は実際にホスト言語に統合される必要はない。
【図面の簡単な説明】
【図１】  本発明に関するコンピュータネットワーク環境を示すブロック図である。
【図２】  本発明を組込んだデータベース管理システムを示す図である。
【図３】  図２のＤＢＭＳによって実行される機能のフローチャートである。
【図４】  本発明によるピボット及び逆ピボットの演算の例を示す。
【図５】  本発明によるピボット演算のフローチャートである。
【図６】    逆ピボット演算のフローチャートである。
【図１】
0004504560.tif 000002
【図２】
0004504560.tif 000003
【図３】
0004504560.tif 000004
【図４】
0004504560.tif 000005
【図５】
0004504560.tif 000006
【図６】
0004504560.tif 000007