JP2002507795A

JP2002507795A - 関係型データベース・テーブルにおける構成変更方法

Info

Publication number: JP2002507795A
Application number: JP2000537159A
Authority: JP
Inventors: ゲーツグレイファ; ジェフアルガー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1998-03-16
Filing date: 1999-03-16
Publication date: 2002-03-12
Anticipated expiration: 2019-03-16
Also published as: AU3092099A; ATE246823T1; DE69910219D1; WO1999048029A1; EP1101172A1; DE69910219T2; US6298342B1; EP1101172B1; JP4504560B2

Abstract

(57)【要約】【課題】関係型データベース・テーブルにおける構成変更方法を提供する。【解決手段】「ピボット」オペレーションは、関係データベース・テーブルにおけるデータ項目を回転させ、前記テーブルにおける一定のデータ値が、前記ピボットされたテーブルのカラム名になるようにし、及び特定された値カラムのデータ項目は、前記ピボットされたテーブルの新しいカラムにおける対応する列に現れる。ピボット・リストは、前記ピボット・カラム・データ項目の一定の値のみが、前記オペレーションに関与するように規定する。入力テーブルの追加のカラムは、出力テーブルにおいてカラムとして現れる；前記出力テーブルの前記列は、これらの分類カラムにおいて、等しいデータ−項目値によって分類される。「非ピボット」オペレーションは、前記ピボット・オペレーションの逆を供給する。両方のオペレーションは、代数レベルで、ＳＱＬユーザ照会に入れ子されてもよい。前記オペレーションは、関係データベース管理システムの検索エンジンにおいて出現してもよく、また、他の照会の最適化の一部として呼び出されてもよい。

Description

【発明の詳細な説明】

【０００１】

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

本発明は、電子データ処理に係り、特に、関係型データベース及びそれに類す
る形式のデータベースのデータ管理ソフトウェアにおけるテーブル処理のための
新しいクエリ・オペレーションに関する。

【０００２】

【従来の技術】

（発明の背景）データベースとは、編成構造化されたデータの集合体である。通常のデータベ
ースでは、各々のデータが、文字列、数値、他の場所に置かれたデータに対する
ポインタ等の特定内容のデータ項目を含む数々のフィールドを持ち、それらデー
タはレコードのセットとしてコンピュータに記憶されている。関係型データベー
スには、相当数の矩形テーブルが含まれている。各テーブルはレコードセットを
持ち、各レコードはそのテーブルの列と呼ばれる。同じテーブル内にあるレコー
ドは、それぞれ同じ数のフィールドを持っている。（しかし、レコードのいくつ
かのフィールドにはデータが含まれておらず、このデータを持たないフィールド
は、ＮＵｌｌ値を持っていると言われる。）テーブルのフィールドは、名前を指
定することができる行のセットから構成されているが、この名前はデータそれ自
身の一部ではない。レコードは、それらを個々に特定する外部的要素を持ってい
ない。その代わり、これらデータには、あるフィールドの組合せから成るキーを
使ってアクセスされる。つまり、関係型データベースは、ソフトウェアにより実
行される連想メモリと考えることができる。

【０００３】データベース管理システム（ＤＢＭＳ、或いはデータベースシステム）とは、
データベースにおいてデータを記憶し維持管理し検索するためのコンピュータソ
フトウェアである。通常、ＤＢＭＳは、索引、ロギング、レコードロッキング等
の、性能、信頼性、完全性を高める機能要素を備えている。また、ＤＢＭＳは、
データベースから特定のデータを探し出すために、これらクエリをサーチエンジ
ンに与える一つ又は複数のインターフェースを常備している。サーチエンジンは
、データベースを検索し、通常、その結果をクエリの仕様に合わせた関係テーブ
ルの形でユーザーに伝える。

【０００４】最も良く知られている関係型データベースのインターフェースは構造化クエリ
言語（ＳＱＬ）である。このインターフェース言語には多くの種類があるが、米
国規格協会（ＡＮＳＩ）や国際標準化機構（ＩＳＯ）により標準版が設定されて
いる。

【０００５】現在最も商業化されているＳＱＬは、これらの標準版に従ったものであるが、
それらの多くは、標準で設定されたもの以外の言語要素を含んでおり、言換える
と様々な標準対応レベルで言語構築されている。

【０００６】関係型データベースや関係型クエリ言語は、矩形テーブルのセットとしてデー
タを取扱う。しかし、多くのデータベースは、理論的には多次元であり、例えば
時間｛日、月、年｝、場所｛店舗、市、州｝、カテゴリー｛製品、製品グループ
｝、関係者｛会社員、部門、本部｝、支払｛現金、小切手、クレジット｝等の軸
に基づくものである。ユーザーは、多くの集合体から成る１つの集合体としてこ
のようなデータを考えることに有用性を見出すことが多く、これらデータを色々
な観点から見たいと望んでいるかもしれない。上述した例において、１つの観点
としては、各レコードが場所を象徴しその場所に関する毎月の売上データの集合
体を含むようなレコードの集合体である場合で、他の観点では、各レコードが時
刻を表し各レコードのフィールド（即ち、テーブルの行）が様々なカテゴリーに
ついての売上数値を集合するようなレコード（即ち、テーブル列）の集合体が考
えられる。

【０００７】この視点から、データの次元をある観点から他の観点に変更するようにデータ
ベーステーブルを構成変更できるようにすれば、従来のＳＱＬのようなクエリ言
語に更なる有益な能力が付加されることになる。本明細書において、観点即ち次
元を変更するということは、行セットとしてテーブルに表された次元を、列セッ
トとして表された次元で置換えることを意味する。従来の関係型ＤＢＭＳ製品及
び標準機種では、観点を変更するための直接的なオペレーションを行うことはで
きない。これを間接的に行うためにＳＱＬクエリを作ることは可能であるが、こ
のようなクエリは、大規模で複雑であり、またエラーが発生し易く処理速度も遅
く、更に並列処理が可能な場合であっても最適な状態で効率的な実行計画に移す
のは困難である。

【０００８】一部のスプレッドシート（ワークシート）のソフトウェアには、ユーザー選択
の矩形セルデータの置換えを、マトリクス代数「転置」オペレーションにおいて
行列要素αijをαjiに移動させるのと同じ方法でユーザーが行えるものがある。
例えば、マイクロソフト・エクセルのピボットテーブルでは、ユーザーは、矩形
セルを選択してテンポラリー・クリップボードにコピーし、オプションメニュー
から「移行」を選択した後に目標セルを指して「特殊な貼り付け」オペレーショ
ンを行う。更に、ユーザーは、マイクロソフト・オフイス等の互換性のあるアプ
リケーションプログラム一式を使って、マイクロソフト・アクセスのデータベー
ス構成要素であるデータベーステーブルからデータを選択し、そのデータを、矩
形スプレッドシート・セルのようなエクセル構成要素に対し単独オブジェクトと
して移してそのセルを置換え、次に、そのセルを置換えられたフォーマットの状
態のレコード集合体としてアクセスデータベースに転送することもできる。

【０００９】この方法によるデータ項目の置換えは、下手なやり方でもあり機能的にも制限
されたものである。小規模のデータベースであっても、１つのクエリを実行する
ためだけに他のアプリケーションプログラムを呼出すのは無駄が多い。大規模な
データベースに関しては、置換えられたデータがメモリ内に残るという従来の要
件により、この方法を行うことは不可能となっている。ホストコンピュータを基
盤としたサーチエンジンを使用したクライエント・サーバ・アーキテクチャに関
しては、このオペレーションを行うために、スプレッドシート・プログラムに接
続する方法は存在しない。どのような環境下においても、スプレッドシートによ
る移行には必ず手作業が伴うため、クエリの内的部分をデータベースプログラム
内に構成することにより置換えを行うことはできない。このような外部オペレー
ションは、従来のデータベースのクエリプロセスや他のサーチエンジンにおける
最新式への再設定、再書換え、他の最適手順に関与することはできない。より概
念的レベルにおいては、スプレッドシートと関係型データベーステーブルとの基
本的な差異によって、望ましい置換え形式を採ることが妨げられている。例えば
、データベーステーブルの行即ちフィールドの名前は、テーブルそれ自体の一部
ではない。つまり、スプレッドシートにおける行の索引がスプレッドシート内で
はセル列にあるという点で、それらデータベーステーブルのフィールドの名前は
、テーブルのレコードにはならない。このように、スプレッドシートの列がテー
ブルのレコードとしてデータベースプログラムに戻される場合、スプレッドシー
トの矩形セルを置換えることにより、セルの行をデータベーステーブルにおける
行の名前に構成変更することはできない。

【００１０】マイクロソフトＳＱＬサーバの実行エンジンは、更新項目ストリーム内に（ｒ
ｏｗ_ｉｄｅｎｔｉｆｉｅｒ、ｏｌｄ_ｖａｌｕｅｓ、ｎｅｗ_ｖａｌｕｅｓ）という書式を持つテーブル更新の各項目を、特定の列値及び行値を置換える「削除
項目」と「挿入項目」とに分離するための厳密なオペレーション、及び「削除項
目」と「挿入項目」とを「更新項目」に置換えるための類似したオペレーション
を行う。これらのオペレーションは、ユーザー向けに用意されたものではなく、
更にユーザークエリに関与することもできない。つまり、クエリプロセスは、デ
ータベースを更新している間に実行される特定機能の効率的実行を促進するため
だけに内部的にこれらオペレーションを利用しているに過ぎない。

【００１１】このように、特に関係型データベースに対し、観点を迅速且つ効率的に変更す
る機能を付与することにより、データベース技術は飛躍的に拡充される可能性が
ある。更に、変更即ち置換えのオペレーションにおいて、その意味及び構文が通
常の拡張としてのＳＱＬ等のクエリ言語にうまく組込まれ、従来の構造化された
データベースクエリ・プロセッサや他のサーチエンジンでも、複雑或いは特異な
機能を必要とせず、最適化され実行することができるようにするというニーズも
存在する。

【００１２】

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

（発明の要約）本発明は、テーブルのデータ項目に異なる観点を設定するために、関係型デー
タベースに定義されているテーブルの列（レコード）と行（フィールド）とを置
換える「ピボット」オペレーションを提供する。本オペレーションは、入力テー
ブルとピボット仕様とを受取り、出力テーブルを作り出す。また、本オペレーシ
ョンは、従来のデータベースクエリプロセス、サーチエンジン、及びサーバに簡
単に組込まれるような方法によりインターフェース言語構成内で行われる。更に
、本オペレーションは、フィールドそれら自身の名前として1つ又はそれ以上の指定されたテーブルの行の値を使用して、特定テーブルレコードのフィールド内
のデータを、異なるレコードの同じフィールド内に置換える。これ以外の行のデ
ータは、ピボット化されたテーブルのデータ値によりグループ化される。

【００１３】最終的な結果が元の観点を持つような場合においても、データベーステーブル
において他の観点から他の関係オペレーションを実行する方がより簡単な場合が
ある。従って、本発明は、ピボット機能の逆機能としての「非ピボット」オペレ
ーションも提供する。また、記憶されたテーブル即ち中間的結果を非ピボット化
することが望ましい場合もある。

【００１４】本オペレーションは、これらオペレーションをデータベースクエリに組込む簡
易で直感的な方法に加えて、クエリの書込みを簡素化するとともに、よりエラー
の起こりにくいものとする。例えば、本オペレーションは、テーブルをこれらオ
ペレーションに結び付ける必要性を減らす若しくは皆無とする。本オペレーショ
ンを行う方法によれば、簡単で有効な構文拡張と明確に定義された意味とを持っ
た状態で、深層にネスティングされた複数のオペレーションを行うことが可能と
なり、良く知られているプログラム言語例が用いられる。クエリにおける方法論
としてテキストの使用を可能とすることにより、幅広いＳＱＬ言語をより有効且
つ簡単に使用することができる。更に、このような形で使用することができる関
係代数式のセットを非手続き型のクエリ式に拡張する方法は、「ｓａｍｐｌｅ」
、「ｔｏｐ」、「ｒａｎｋ」等の他のオペレーションにも適用することができる
。

【００１５】本発明によるピボット及び非ピボットオペレーションは、特に関係型データベ
ースを含む各種データ操作ソフトウェアやシステムアーキテクチャと本質的に互
換性を持っている。これらオペレーションは、言語レベル（例えば、ＳＱＬや他
のクエリ言語に対する直感的拡張を用いることによる）、及び処理レベル（例え
ば、クエリ最適化やクエリ実行）のいずれにおいても上記したシステムに組込む
ことができる。

【００１６】複数のデータソースがそれぞれ異なる形、つまり異なる列/行の比を有する場合、複数のデータベースから単一のデータウェアハウス・データベースにデータ
を組込むと、「インピーダンス不適合」の問題に直面することが多い。定義付け
を主な要因として、このようなデータベースは、相当大規模なものとなる可能性
がある。このようなデータを正規化するか否かは、状況次第である。つまり、ピ
ボット化されたフォーム即ち観点にデータを記憶することは、１つのデータ構成
にとって最適−つまり、まさに必要−であるかもしれないが、他のデータ構成は
、非ピボットフォームを選択即ち必要とするかもしれない。従って、ピボット及
び非ピボットオペレーションを付加することは、異なるソースからのデータ、特
に多量のデータの組合せにとって大きなメリットとなる。

【００１７】また、本発明によって提供される新しいオペレーションにより、低レベルのＤ
ＢＭＳ処理は、例えシステムソースが限られた状態にあるにしてもその効率が高
められる。この新オペレーションの拡張可能な構文及び明確な意味により、特に
より効率的な実行のためにクエリを書換える場合において、複雑なクエリの自動
的な生成と最適化が促進される。これにより、索引の更新処理、完全性の保守管
理等の純粋に内部的なＤＢＭＳ機能も恩恵を受ける。また、「ＩＮ」、「ＯＲ」
、及び「ＵＮＩＯＮ」等のクエリを含むＳＱＬクエリの処理を改善することがで
きる。クエリによる「ＧＲＯＵＰ」用に既に使用されている多くの最適化技術は
、ピボットや非ピボットクエリを処理するために通常どおり使用することができ
る。これらクエリのための並列処理技術を含む従来の実行アルゴリズムは、選
別されておらず且つ区分化されているテーブルや結果を含むピボット化されたテ
ーブル即ちクエリ結果に適用される。

【００１８】本発明の他の特徴や利点及び本発明の範囲内にある変形例は、以下の詳細な説
明により当業者に示されるであろう。

【００１９】

【発明の実施の形態】

（発明を実施するための最良の形態）模範的な動作環境データベース管理システムは、独立型パーソナル・コンピュータ（personal c
omputer）、中範囲（midrange）及びメインフレーム・コンピュータ（mainframe
computer）、ピアトゥピア（peer-to-peer）並びにクライアント／サーバ・ネットワーク（client/server networks）、及び多くのアーキテクチャの広範囲分
散型システムを含む、多くの異なる種類のデータ処理システムにおいて実行され
る。すべてのデータ処理システムは、本発明に適した環境である。しかしながら
、説明の目的で、本発明は図１に記載された従来のクライアント／サーバ・コン
ピュータ・システム１００に関連して説明される。ネットワーク配線１１０は、
多くのパーソナル・コンピュータ（ＰＣｓ）１２０を、ネットワーク・アダプタ
１２１及び１３１を介してサーバ１３０に相互接続する。サーバ１３０は、大量
のデータを通常の企業データベースに維持するための記憶サブシステム１３２を
含む。他のシステム・アーキテクチャもまた、本発明に適した環境である；例え
ば、装置１２０は、メインフレーム又は中範囲コンピュータ１３０に接続された
ターミナルでもよいし、又は装置１３０それ自身が、ピアトゥピア・ネットワー
クにおけるＰＣｓ１２０に接続されたＰＣを具備してもよい。小型の及び小さめ
のデータベースに対しては、システム１００全体は、クライアント及びサーバの
両方として動作する単一のＰＣを具備してもよい。同様に、ファイル記憶装置は
、多くの異なるマシンの間で分散されてもよい。図１は、クライアントへの分散
及びダウンロードのためのクライアント及びサーバ・ソフトウェアを記憶しても
よい外部記憶媒体１３３、及びデータベース・テーブル（database tables）のオフライン記憶装置のための、ディスケット（diskette）等の他の媒体１３４を
図示したものである。

【００２０】図１Ａ及び以下の検討は、パーソナル・コンピュータ１２０の簡潔な、一般的
な説明を提供することを意図する。要求はされないが、本発明は、例えばプログ
ラム・モジュール（program module）等の、パーソナル・コンピュータで実行さ
れるコンピュータ実行可能型命令の一般的な文脈で説明されるであろう。一般的
に、プログラム・モジュールは、特定のタスクを実行し又は特定の抽象データ型
を実行するルーチン（routine）、プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに当業者は、本発明が、ハンドヘルド（hand-held ）機器、マルチプロセッサ・システム、マイクロ・プロセッサ−ベース又はプロ
グラム可能民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレ
ーム・コンピュータ等を含む、他のコンピュータ・システム構成で実行されても
よいことを評価するであろう。本発明はまた、タスクが、通信ネットワークを通
してリンクされた分散型理装置によって実行される、分散型計算環境において実
行されてもよい。分散型計算環境において、プログラム・モジュールは、ローカ
ル及び遠隔両方の記憶装置に配置されてもよい。

【００２１】図２は、図２に記載のシステム１００において動作することができる一般的な
従来のクライアント／サーバ・データベース管理システム２００のブロック図で
ある。クライアント・アプリケーション・プログラム（client application pro
gram）２１０は、マイクロソフト・ウィンドウズ（Microsoft Windows）９５等のＰＣオペレーティング・システム（operating system）２２０の下で、各ＰＣ
の中で実行する。他の機能の中でも特に、クライアント・アプリケーション２１
０は、ＰＣ１２０におけるユーザからのデータベース照会を受け付けるための機
能２１１を含む。ユーザ・エントリ（user entry）に加えて、ＰＣ１２０のいく
つかにおいて実行する他のアプリケーション・プログラム２３０は、予め定義さ
れたホスト言語のアプリケーション−プログラム・インターフェース (applicat
ion-program interfaces）（ＡＰＩｓ）２３１を介して、ＤＢＭＳクライアント
２１０への照会を表示してもよい。

【００２２】サーバ１３０の中で、例えばマイクロソフトＳＱＬサーバ（Microsoft SQL Se
rver）等のＤＢＭＳサーバ・アプリケーション２４０は、例えばマクロソフト・
ウィンドウズＮＴ（Microsoft Windows NT）等のサーバ・オペレーティング・シ
ステム（server operating system）２５０の下で実行する。ＤＢＭＳプログラム２４０は、データベース２６０によって例示された、多くの関係データベース
を生成し、照会し、保守し及び修正するためのサービスを提供する。プログラム
２４０は、オペレーティング・システム２５０のファイル−システム・サービス
（file-system service）２５１を採用してもよく、又は独自のファイル・システムを供給してもよい。オペレーティング・システム２５０は、クライアント２
１０からの各要求に対して、ＤＢＭＳアプリケーション全体の個別のインスタン
ス（instance）を実行することができる。しかしながら、より高い効率のために
、プログラム２４０は、各クライアント接続に、ＤＢＭＳカーネル（kernel）に
おいて個別のスレッド（thread）２４２を付与する。さらに、このスレッドは、
固有のオペレーティング−システム・スレッドでもよく、処理メモリ保護、記憶
装置へのより良いアクセス等のためのすべてのウィンドウズＮＴ機構を伴う。検
索エンジン（search engine）２４１は、以下でより完全に説明されるとおり、データベース２６０のテーブル２６１上で、個人クライアント２１０からの照会
及び他の要求を処理する。それはまた、記録ロック（record locking）、アトミ
ック・トランザクション（atomic transaction）等のための従来の機能で、デー
タベースの完全性を実現する。マイクロソフトＳＱＬサーバにおいて、照会機能
２１１と検索エンジン２４１との間のインターフェース言語は、トランザクトＳ
ＱＬ（Transact-SQL）であり、それは標準ＡＮＳＩＳＱＬ８９及びＡＮＳＩ
ＳＱＬ９２言語の機能のほとんどを、さらにより高い柔軟性及びプログラム可能
性を供給するための拡張機能を供給する。

【００２３】図３は、前記クライアント・アプリケーション２１０のいずれかから転送され
た照会を処理するための、図２に記載された検索エンジン２４１のいくつかの従
来の機能３００を示す。ＳＱＬ照会は、その結果を得るための一連の段階よりも
むしろ、所望の結果の属性又は述語の仕様であるために、ＳＱＬは非手続き言語
である。すなわち、ＳＥＬＥＣＴ年，四半期，売上ＦＲＯＭＮａｒｒｏｗ
Ｗｈｅｒｅ売上＜（ＳＥＬＥＣＴＡＶＧ（売上）ＦＲＯＭＮａｒ
ｒｏｗ）ＯＲＤＥＲＢＹ年,四半期等の照会は、出力テーブルの属性を特定する。前記出力テーブルのカラムは、Ｎａｒｒｏｗと名づけられた入力テー
ブルから引き出された年，四半期，及び売上と名づけられたカラムに対応する。
前記出力−テーブル列（記録）は、年で、それから各年の値の中の四半期で並べ
られ（すなわち分類され）る。前記出力に現れる前記入力テーブルからの記録は
、売上の値が、Ｎａｒｒｏｗと名づけられたテーブルにおける売上のすべての値
の平均値よりも小さい場合のものだけである。ＳＥＬＥＣＴＡＶＧ（売上）
ＦＲＯＭＮａｒｒｏｗという入れ子型副照会（nested subquery）は、単一のカラム及びＮａｒｒｏｗテーブルにおける売上の平均値を含む単一の列のみを有
するテーブルを生成する。前記入力テーブルの記録がアクセスされる方法並びに
順番、及び前記出力テーブルを作成するための手続き又は方式（plan）の他の詳
細は、照会それ自身によっては定義されない。

【００２４】検索エンジン２４１は照会を受け取ると、段階３１０に記載のとおり、前記照
会を内部又はトークン化された（tokenized）形式に解析する。確認（validatio
n）段階３２０は、照会において名づけられたデータが実際にデータベースに存在することを確証し、及びデータと完全性拘束条件を調べる。それは、前記照会
のある部分、例えば２３１におけるマクロ（macro）やビュー（view）を拡張してもよい。出力３２２は、あらゆるエラーを、ユーザ又は照会の他のソースに報
告する。最も制約された検索エンジンを除くすべては、段階３３０に記載のとお
り、照会の時に大規模な最適化を実行する。最適化は、照会の部分を結合し又は
分割し、オペレーション及び副照会等を再編成し、及び記憶されたデータベース
・テーブルの記録へのアクセスを順番に実行し及び機能を修正する等の他の方法
によって、前記照会を書き換えることに関与してもよい。各候補実行戦略（cand
idate execution strategy）に対して、それらは、この戦略を使用して前記照会
を実行するために必要となる演算時間又はリソースを表す費用値を計算し、それ
からすべての可能性のある候補の中から一つの戦略を選択する。これらの最適化
プログラム（optimizer）を設計する技術は複雑であり難解であるが、当業者は、様々な種類の新しい照会機能を含むように、従来の最適化プログラムを適応さ
せる能力を有する；他の、より手続き的な言語に対する翻訳プログラムの設計者
もまた、この同じ一般的なクラスの最適化プログラムを定期的に構築する。調査
論文、Ｍ．ジャーク及びＪ．コック「データベース・システムにおける照会最適
化」、ＡＣＭコンピューティング・サーベイ（ACM Computing Survey）１６，２
（１９８４年６月），１１１ページでは、データベース照会最適化プログラムの
構造がより詳細に議論された。

【００２５】前記段階３３０の出力は、前記照会に回答するための照会評価方式（又は単に
「方式」）である。段階３４０はこの方式を、通常は従来の関数ツリーとして表
示される、手続き的形式にコンパイルする。段階３５０は、データベース・オブ
ジェクト（database objects）に対する方式を実行するための、単純なツリー走
査アルゴリズム（tree-traversal algorithm）をランさせてもよい。前記段階３
５０の出力は、前記照会のソースに戻される出力テーブルの形式の、前記照会の
結果である。ここに記載された一つ以外の検索エンジンは、個別の段階３００を
結合し又は分割してもよく、又は段階を省略し又は追加してもよい。他の調査論
文、Ｇ．グレーフ「大規模データベースのための照会評価技術」ＡＣＭコンピュ
ーティング・サーベイ２５，２（１９９３年６月），７３ページは、参照のため
にここに採用されており、照会の実行の問題を扱い、及び追加の説明及び議論を
供給する数多くの参照を引用している。また、最新の検索エンジンの段階は、新
しい構文、新しい検索機能、最適化知識及び実行技術を備えるための容易な拡張
性のために特定的に設計されている。

【００２６】ピボット及び非ピボット・オペレーション図４は、本発明に従ったピボット・オペレーションの構造を示す。このオペレ
ーションは、関係代数のレベルでのＳＱＬオペレーションの階層に適合する。関
係データベース・システム及びインターフェースを設計する人は、照会処理を３
つのレベルに分割する。関係の数学的理論は、この種類のデータベースに対する
概念的フレームワークを供給するので、第一及び第二のレベルはしばしば、関係
論理及び関係代数と称される。

【００２７】関係論理は、あらゆる微積分と同様に、結果を得るためのあらゆるオペレーシ
ョン、手続き又は他の方法に名前を付けることなく、所望の結果の高いレベルで
の説明又は仕様を扱う。すなわち、それは単にデータベースにおける現存の関係
について、所望の結果の関係（テーブル）の定義を表現する。例えばＳＥＬＥＣ
Ｔ従業員名，部署名ＦＲＯＭ従業員，部署ＷＨＥＲＥ従業員．ｄｅｐ
ｔ＿ｉｄ＝部署．ｄｅｐｔ＿ｉｄという照会は、結果関係の典型的なメンバ及び
前記結果メンバの定義属性を表す修飾に関する一つ以上の入力テーブルに関して
、出力テーブルの属性及び制約を記述する。関係論理は、データベース、テーブ
ル（「関係」）、及び照会の正式で、正確な理解のための根拠を供給し、及び現
在はＡＮＳＩ／ＩＳＯ標準であるデータベース言語ＳＱＬの検索コンポーネント
における商業的実現を見た。ＳＱＬがデータ管理製品で果たす重要な役割がある
とすると、現実世界のためにデータベース機能を拡張することは、追加されたあ
らゆる機能が、ＳＱＬ言語の構文的及び意味的に簡潔な拡張になることを要求す
る。

【００２８】関係代数は、よりオペレーション指向（ではあるが同等）の関係論理である。
関係代数におけるオペレーション又は関数は、一つ以上の入力テーブルを使用し
、及び規則にしたがって出力テーブルを生成する。例えば、ＪＯＩＮ［従業員．
ｄｅｐｔ＿ｉｄ＝部署．ｄｅｐｔ＿ｉｄ］（従業員、部署）という関係オペレー
ションは、両方のテーブルにおいてｄｅｐｔ＿ｉｄと名づけられた共通のカラム
又はフィールドに沿って、従業員及び部署と名づけられたテーブルを結合する。
（これは、加法等のオペレーションに類似しており、例えば、「４＋５」という
オペレーションが「９」を生成するように、２つの数を使用し、第三の数を生成
する。）関係代数の重要な特性は：（１）オペレーションは、同じ種類のオブジ
ェクト、すなわち関係式を使用し及び生成する；（２）オペレーションは、任意
で複雑な構造に入れ子されることができる；及び（３）新しいオペレーションが
追加されることができる、ということである。関係代数において、入力オブジェ
クトは、入力を有するだけではなく、追加の情報を表すタグを備えていてもよい
。すぐ上述の例においては、ｊｏｉｎというオペレーションは、２つの関係代数
式、すなわち結合されるべき２つのテーブル（従業員、部署）を特定するだけで
なく、：各テーブルにおける特定のカラムの等しい値［従業員．ｄｅｐｔ＿ｉｄ
＝部署．ｄｅｐｔ＿ｉｄ］に沿って、それらがどのように結合されるべきかを特
定する「結合述語」を指定する。

【００２９】いくつかの大変有用な照会オペレーションは、関係論理レベルで表現すること
は困難であるが、それらは簡単に及び簡潔に関係代数レベルに積分することがで
きる。例えば、ＯＵＴＥＲＪＯＩＮは関係ＪＯＩＮオペレーションの変形であ
り、単純なＳＥＬＥＣＴ．．．ＦＲＯＭ．．．ＷＨＥＲＥという照会構文には容
易に又は簡潔には適合しない。そのために、ＡＮＳＩ／ＩＳＯは、ｆｒｏｍ文節
におけるテーブル、例えばＳＥＬＥＣＴ従業員名部署名ＦＲＯＭ従業員
ＬＥＦＴＯＵＴＥＲＪＯＩＮ部署ＯＮ従業員．ｄｅｐｔ＿ｉｄ＝部署
．ｄｅｐｔ＿ｉｄに代わって、一組の制限された関係代数式を許可する。すなわ
ち、関係代数式で関係論理型照会を拡張するための先例があるが、そのような拡
張は、ＪＯＩＮオペレーションの変形にかなり制限されてきた。関係代数オペレ
ーションはしばしば、図３に記載されたブロック３３０におけるとおり、選択（
selection）、射影（projection）、集約（aggregation）及び関係論理レベルで
の他の非手続き的仕様を有する照会の最適化に関与する。

【００３０】照会実行方式は、第三の及び最低レベルの照会処理を構成する。関係代数オペ
レーションの入れ子は、実行の順番を示すかもしれないが、中間結果を生成する
ための特定の命令のアルゴリズム又はセットは、より高いレベルよりもむしろ、
実行方式のレベルで発生する。例えば、関係ＪＯＩＮオペレーションを実行する
ための３つの基本的方法：入れ子ループ（loop）、マージ結合及びハッシュ結合
がある；各方法は、大量の変形を有する。実行方式は、そのような選択肢からの
選択を明確に示し、及び図３に記載のブロック３４０において、照会処理の最低
レベルで公式化される。

【００３１】関係照会処理は、大変正確に及び確定的構造的フレームワーク内で定義される
ので、すべての３つのレベル：言語拡張、関係代数オペレーション、及び実行方
式で、あらゆる新しい機能を定義することが重要である。本発明は、ピボット及
び非ピボット機能を、言語への拡張として、ＳＱＬ照会において明確に関与する
新しい関係代数オペレーションとして供給してもよい。

【００３２】有効な照会式である第一の標準的な形式での入力テーブル−式のための、ピボ
ット・オペレーションの正式な定義は：テーブル．ＰＩＶＯＴ（＜値＿カラム＞
ＦＯＲ＜ピボット＿カラム＞ＩＮ（＜ピボット＿リスト＞））である；出力
のピボットされたテーブルはまた、有効な第一の標準的形式のテーブルである。
最も外側の括弧の間のテキストは、ピボット・オペレーションの仕様を構成する
。ピボット仕様における最初の２つのカラムは、ピボット・オペレーションの入
力テーブルにおけるカラムでなければならない。これらのカラムは、ピボット・
オペレーションの出力テーブルには現れない。その代わり、ピボット仕様の中の
ピボット・リストにおける各値は、ピボット・オペレーションの出力テーブルに
おける新しいカラムを定義する。入力テーブルにおいては、ピボット・リストに
おけるエレメントは、ピボット・カラムにおける値として現れる。値カラムにお
ける対応する値は、出力テーブルでの新しいカラムにおける値になる。「分類カ
ラム」と称される、ピボット仕様に含まれない入力テーブルにおけるすべてのカ
ラムは、出力テーブルに引き継がれる。

【００３３】図４に記載の例４００では、仕様４２０に従って入力テーブル４１０をピボッ
トすることで、出力テーブル４３０を生成する。Ｎａｒｒｏｗと名づけられた入
力テーブル４１０において四半期と名づけられたピボット・カラム４１１は、出
力テーブル４３０において４つのカラム４３１、４３２、４３３、及び４３４に
なる。これらのカラムの名前は、春、夏、秋、冬、という４つの特有の値であり
、カラム４１１においては値として現れ、また４２０においてはＩＮというキー
ワードに続く値のリストにおいて現れる。値カラム４１２における売上の数は、
４つのカラム４３１乃至４３４のうちの対応するものにおける値として現れるが
、同じ地域及び年に対する売上の数は、同じ列になるようにピボットされ又は回
転される。分類カラム４１３乃至４１４は、出力４３０においてカラム４３５乃
至４３６として現れる。仕様４２０がＧＲＯＵＰＢＹ地域、年という形式の
ＳＱＬ文節を含んでいたかのように、出力において、前記列は、第一の分類カラ
ム４１３の等しい値によって、それから第二の分類カラム４１４の等しい値によ
って分類される。この例においては、ピボット・オペレーションの効果は、デー
タが見える見え方を修正することである。入力テーブル４１０は、主として企業
のＮａｒｒｏｗ地域に対する年間のデータ傾向を示す一方で、出力テーブル４３
０は、四半期による季節的追跡を許可する。（関係テーブルにおける前記列は、
名前を有しないし、特定の順番もないことがここで思い出されるべきである。カ
ラムは名前を有し、分類される−すなわち、それらは、その名前が照会において
現れる順番で表示される。）ピボット・オペレーションは、比較的多くの列と及
び比較的少ないカラムを有する入力テーブルを、より少ない列とより多いカラム
を有する結果物としてのテーブルに変換する。

【００３４】出力テーブルにおける前記ピボットされたカラムは、入力テーブルの値カラム
におけるデータと同じデータの種類（ｎｕｍｅｒｉｃ型、ｖａｒｃｈａｒ型等）
を有する。値カラム、ピボット・カラム及びピボットされたカラムは、計算され
た式よりもむしろ、簡潔なデータを具備する。両方のテーブルにおけるカラムの
順番は、ＡＮＳＩＳＱＬにおけるように重要ではない；カラムは、名前によっ
てのみ参照されることができ、位置によってはできない。テーブル４３０は、地
域及び年の分類カラムの値によって分類されるように図示されているが、ピボッ
ト・オペレーションは、前記列の特定の分類又は順番つけは含まない。

【００３５】上述のとおり、入力テーブルにおける列は、その値がピボット・リストに現れ
なければ、出力には現れない。入力−テーブル列は、同等の定義に関して、あら
ゆる分類カラムの等しい値によって分類される。各グループの中では、入力テー
ブルの各列は、互いにピボット・カラムにおいて特有の値を有する。各グループ
は、一つの出力列という結果になる。対応する入力列を有しない出力カラムに対
しては、値は、ＳＱＬで定義された特別な値、ＮＵＬＬである。

【００３６】図５は、ピボット・オペレーションのための図２に記載の検索エンジン２４１
の、図３に記載されたモジュール３００によって実行される段階のフローチャー
ト５００である。ブロック５１０は、図１に記載のクライアント・ターミナル１
２０のユーザ、又はここに記載されたいくつかの他のソースから照会を受け取る
。段階５２０は、データベース２６０におけるどのテーブル２６１が、オペレー
ションの入力テーブルとしての働きをするかを識別し又は選択する。段階５２１
は、入力テーブルのどのカラムがピボット・カラムになるのかを識別し、段階５
２２は、どのピボット−カラムの値がピボットに関与するかを、前記ピボット・
リストから識別し、及び段階５２３は、前記入力のどのカラムが値カラムである
かを選択する。段階５３０は、他のテーブル２６１として出力を作成する。段階
５３１は、各データ−項目値のための個別のピボットされたカラムを、前記ピボ
ット・リストに配置する。段階５３２は、もしあれば、前記分類カラムを作成す
る。（前述のとおり、これらは、ピボット仕様において識別されなかった入力テ
ーブルのあらゆる追加のカラムである。）段階５４０は、上述のとおり、前記値
カラムのデータ−項目値を前記出力テーブルの列に挿入する；一つの方法は、段
階５４１で示されたように、転置（transposition）によるものである。この転置を表現するための他の方法は、前記値カラムにおける各データ項目が、ピボッ
トされたカラムの一つ、すなわち前記入力テーブルの前記ピボット・カラムにお
けるデータ値と同じ名前を有するカラムへと配置されることである。段階５５０
は、出力−テーブル列を、あらゆる分類カラムの等しい値によって分類する。最
後に、段階５６０は、図２に記載のデータベース２６０に前記出力テーブルを記
憶する。

【００３７】非ピボット・オペレーションは、ピボット・オペレーションの逆であり、及び
＜テーブル＿式｜照会＿式＞．ＵＮＰＩＶＯＴ（＜値＿カラム＞ＦＯＲ＜
ピボット＿カラム＞ＩＮ（＜カラム＿リスト＞）として形式的に定義される
。前記用語の意味は、前記ピボット・オペレーションに対するものと同じである
。同じ仕様を有するピボット及び非ピボット・オペレーションを入力テーブルに
適用することで、前記入力テーブルをその本来の状態に戻す。図４に記載の例に
おいて、前記非ピボット・オペレーションをピボットされたテーブル４３０に適
用することで、テーブル４１０を元に戻す；売上４１２及び四半期４１１と名づ
けられた前記２つのカラムは、カラム４３１乃至４３４に取って代わる。

【００３８】入力テーブルにおける各列に対して、前記非ピボット・オペレーションは通常
、一つのピボットされたカラムに対して、出力テーブルの一つの列を生成する。
（しかしながら、ピボットされたカラムにおけるナル値は、出力列を生成しない
。）前記ピボット・リストにおけるすべてのカラムは、前記入力において同じデ
ータ種類を有していなければならず、及び前記出力の値カラムにおけるエントリ
は、この種類を有するであろう。テーブルをピボットさせないことは、その列の
数を増加させ、及びカラムの数を減少させる。また、図４は分類−カラム値によ
って分類されたテーブル４１０を示しているが、前記非ピボット・オペレーショ
ンは、前記出力において列の分類がないことを示す。

【００３９】図６は、非ピボット・オペレーションのための図２に記載された検索エンジン
２４１の、図３に記載されたモジュール３００によって実行される段階のフロー
チャート６００である。段階６１０は、前記非ピボット・オペレーション及びそ
の仕様を受け取る。非ピボットは、ピボットの逆になるように、及びピボットさ
れたテーブルを正確にそのピボットされていない形式に戻すように定義されてい
るので、非ピボットの仕様は、ピボットのためのそれに補足的ではなく、むしろ
図４に記載の４４０において示されたとおり、前記ピボットされたテーブルを第
一の場所に生成した仕様のそれとまったく同じ形式を有する。また、段階６１０
は、前記オペレーションをユーザ照会又は他のソースから受け取ってもよい。段
階６２０は、ピボットされるべきでない２６１等の前記ピボットされたテーブル
を識別し又は選択する。このテーブルは、実際に以前のオペレーションでピボッ
トされている必要はないが、通常はされているであろう；すなわち、前記ピボッ
ト・オペレーションは通常、見える角度の最初の回転を達成するために使用され
、及び非ピボットは通常、テーブルを簡潔で単純な方法で、本来のピボットされ
ていない形式に戻すためだけに使用される。段階６２１は、前記仕様のピボット
・リストを使用して、どのカラムが、回転され又は転置されるべきピボットされ
たカラムであるかを識別する。段階６２２及び６２３は、前記値カラム及び前記
ピボット・カラムの名前を識別する。（少なくとも、以前のピボットがこの情報
を保存しているサイド・テーブル（side table）を保持していないかぎり）前記
ピボットされたテーブル内のどこにも現れないので、これらの名前は前記仕様に
含まれる。

【００４０】段階６３０は、前記非ピボット・オペレーションによって生成されるべき前記
ピボット・テーブルを作成する。段階６３１及び６３２は、段階６２２及び６２
３において供給される名前を使用して、前記ピボット・テーブルにおいてピボッ
ト及び値カラムを形成する。段階６３３は、前記ピボット・テーブルにおいて分
類カラムを作成し、それは、段階６１０において受け取られる非ピボット仕様に
含まれない前記ピボットされたテーブルのカラムの各々に対して一つである。段
階６４０は、前記ピボットされたテーブルからのデータ項目を、前の段階におい
て作成された前記ピボットされていないテーブルに転置する。前記ピボットされ
たカラムの名前は、異なる列においてデータ項目になり、及び前記ピボットされ
たカラムにおける前記データ項目は、本来の（ピボットされた）テーブルにおい
て、それらが存在していたピボットされたカラムの名前と同じピボット−カラム
値をそれぞれ有する列において、新しい値カラムに入る。段階６５０は、分類−
カラム列の等しい値によって列を分類する。段階６６０は、図２に記載のデータ
ベース２６０に離して前記テーブルを記憶する。

【００４１】前記ピボット、値及びピボットされたカラムは、単純なデータであって、計算
された値ではないので、相関変数は、ピボット及び非ピボット・オペレーション
の仕様の中では許可されない。これらの新しいオペレーションは、どの相関変数
が、前記オペレーションが適用される照会式において許可されるか、また相関関
数が許可されるか否かについてまったく影響を与えない。ＡＮＳＩＳＱＬが、
ピボット又は非ピボット・オペレーションが起こらない照会式のためのテーブル
及びカラム・エイリアス（alias）を定義することを許可するなら、ピボット／非ピボット・オペレーションを含む前記照会式に対する前記エイリアスを定義す
ることは容認されるが、前記オペレーションを除く前記照会式に対しては容認さ
れない。例えば、テーブル１ＡＳテーブル２（ｃｏｌ１，ｃｏｌ２）が許可
される場合、テーブル１．ＰＩＶＯＴ（．．．）ＡＳテーブル２（ｃｏｌ１，
ｃｏｌ２，．．．）は容認されるが、テーブル１ＡＳテーブル２（ｃｏｌ１
，ｃｏｌ２）．ＰＩＶＯＴは容認されない。

【００４２】前記ピボット及び非ピボット・オペレーションは、図３に記載のブロック３３
０において、あらゆる数の従来の最適化技術を使用してもよい。これらのオペレ
ーションは関係代数レベルの一部であるので、代数照会最適化プログラムは、最
適化技術を実現するために最も適切な伝達手段であるかもしれない。他の最適化
フレームワークも同様に適用可能であるかもしれない。

【００４３】いくつかの追加の最適化技術は、新しいオペレーションの特定の属性を使用し
てもよい。明らかに、ピボット及び非ピボット・オペレーションの隣り合う対は
、互いに相殺してもよいし、照会から削除されてもよい。最適化プログラムは、
前記ピボットされた出力テーブルにおける前記分類カラムが、機能的に前記ピボ
ット及び値カラムを決定することを認識し、それゆえにその結果のテーブルの関
係キーを形成する。（これは、従来のＧＲＯＵＰＢＹオペレーションにおける
前記分類カラムに大変似ている。）非ピボット出力テーブルにおいては、前記分
類カラムは前記ピボット・カラムとともに、機能的に前記値カラムを決定する。
これらの属性は、代替的な実行方式を比較するための選択性の評価及び照会−費
用計算のための出力列の数を評価することに関して助けとなることができる。そ
れらはまた、照会の前記実行を単純化する書き換え規則を適用するための条件を
生成する場合に便利であるかもしれない。テーブルが縦に区切られている場合、
完全な列及びそれに引き続く非ピボットを再アセンブルするためのオペレーショ
ンは、両方のオペレーションを排除して、互いを相殺してもよい。

【００４４】前記ピボット・オペレーションのＳＱＬＧＲＯＵＰＢＹ文節に対する概念
的類似性によって、前記文節を有する照会を最適化するための多くの技術及び規
則は、新しいオペレーションに対しても同様に機能することができる。典型例は
：（１）前記分類入力の大きさを低減させるため、又はより効果的な結合アルゴ
リズムを可能にするために、結合の上にピボットを引くこと；（２）前記結合入
力を低減させるため又は前記ピボットのためのより効果的な実行方式を使用する
ために、結合の下にピボットを送ること；（３）二つの隣接するピボットを併合
すること、おそらく効果的にそれらのうちの一つを排除すること；及び（４）ピ
ボットを二つの部分に分割し、そのうち一つを、結合を通って又は処理境界（pr
ocess boundary）を横切って、並行実行環境におけるローカル／グローバル集約
として送ること、を含む。通常は、−追加のカラムを計算する式を含む−前記分
類カラム及び射影オペレーション（projection operation）上の照会の述部は、
分類オペレーションと同じ方法で、ピボット／非ピボット・オペレーションを（
上又は下を）通って動くことができる。

【００４５】一定の照会述部は、ピボットの結果のテーブルに対する述部（すなわち、修飾
）として取り扱われた時に、実行するのに効果的である−また表現するのにより
簡単である−。例えば、２つのピボットされたカラムを互いに比較することは、
表現するのに簡単であり、及び実行するのに効果的である一方で、前記ピボット
入力テーブルに適用される同じ述部は、複雑で、非効率的な入れ子照会を必要と
する。それゆえに、オペレーションのピボット／選択／非ピボットの順番を含む
ための前記照会の書き換えは、前記照会を最適化するために使用されることがで
きる。例えば、図４に記載のテーブル４１０において、秋における売上が春にお
ける売上を超えるテーブル列を選択するための照会を検討する。ピボットされた
テーブル４３０は、この照会を、春及び秋のカラム４３１及び４３３の間の比較
として備えることができる一方で、本来のテーブル４１０は、前記比較を実行す
るために、前記テーブルがそれ自身に結合することを要求する。図４に記載のテ
ーブルを使用して、ピボット及び非ピボット・オペレーションを（従来の複数行
の形式で）含む大きな照会は：（ＳＥＬＥＣＴ＊ＦＲＯＭＮａｒｒｏｒ．ＰＩＶＯＴ（売上ＦＯＲ四半期ＩＮ（春、夏、秋、冬）
）ＷＨＥＲＥ秋＿売上＞春＿売上）．ＵＮＰＩＶＯＴ（売上ＦＯＲ四半期ＩＮ（春、夏、秋、冬））でもよい。

【００４６】図３に記載のブロック３４０に有用な実行方式は、当業者によって、分類オペ
レーションのための従来の方式から引き出すことができる。特に、ループ、索引
付け、ストリーム、分類、及びハッシングに基づいた方式は、容易に思い浮かぶ
。早期集約分類及び混成ハッシングは、有用な変形である。ピボット／非ピボッ
ト・オペレーションは、共有メモリ、分散型メモリ、共有ディスク及びクラスタ
・マシン等の並行アルゴリズムを含む、並行−実行環境に変更可能である。ロー
カル／グローバル集約はすでに、一つの可能性として述べた。

【００４７】非ピボット・オペレーションは、各入力記録に対する複数の出力記録を生成す
る単一の入力、単一の出力方式のみを必要とする。このオペレーションは、共有
メモリ、分散型メモリ、共有ディスク、及びクラスタ・マシン上で、簡単に並行
して実行することができる。

【００４８】変形及び拡張上述の実施形態に対する多くの変形及び拡張は、単独でも互いに結合しても、
いくつかの応用に有用であるかもしれない。当然、最も明白であるのは、ドット
呼び出し分離文字（dot invocation separator）等の表記規則の置換え又は増補
、及びコンポーネントの再編成である。前述のピボット／非ピボット・オペレーションは、ピボットされたテーブル又は
出力テーブルにおけるカラム名に制限を設ける。標準ＳＱＬにおけるカラム名は
、スペースのない文字列でなければならない。カラム値はスペースを有するかも
しれず、及びピボットは値を名に変えるので、引用された識別子及びリテラル（
literals）をカラム名として使用するための方法を、簡単に案出することができ
る。同様に、文字列以外のデータ種類を有するカラム値を、カラム名に対する印
刷可能な及び読み取り可能な表示として表示することは簡単であろう。名前の連
結等、従来の名前操作は有用であろう。例えば、ピボット・リストは、ＳＱＬの
ＡＳ等のキーワードを使用して、カラム・エイリアスを含むかもしれない。（図
４において、四半期値が季節名の代わりに「１」乃至「４」である場合、４２０
の仕様は、（売上ＦＯＲ四半期ＩＮ（１ＡＳ “春”、２ＡＳ “
夏”、３ＡＳ “秋”、４ＡＳ “冬”））を読み取る。）さらに、Ａ
Ｓはあらゆる文脈においてピボット−結果カラムに再度名づけるために使用され
てもよく、及びユーザ定義機能は、複雑なカラム名を変換するため、又は名前を
ＳＱＬ実行の特定の制約に適合させるために供給されることができる。

【００４９】意味的拡張は、単一の段階での複数のカラムのピボット及び非ピボットを含ん
でもよい。例えば、図４に記載のオペレーション４５０は、３つのカラム４１１
、４１２、及び４１４を、結果テーブル４３０の４つのカラム４３１乃至４３４
の代わりに、８つのカラムと入れ替える。すなわち、ピボット・カラムの組は、
すべてのピボット・リストのカルテシアン積又は外積を表す。前記ピボットされ
たカラムに名前を付けるための規定は、売上＿１９９６＿春等の、名前を結合す
ることに関与するだけかもしれない。同じ仕様での複数カラム非ピボット・オペ
レーションは、この拡張に対して真の逆を供給するように、前記名前をそれらの
本来の形式に復号することができる。さらなる拡張は、複数カラムが段階におい
てピボットすることを許可する。例えば、上述の８つのカラムを生成するために
、さらなるピボットを、カラム４３６についてすでにピボットされたテーブル４
３０に適用することが望ましいであろう。テーブル４３０をピボットせずに複数
カラムのピボットを適用するよりもむしろ、拡張された形式は、値カラム、例え
ばＷｉｄｅ．ＰＩＶＯＴ（（春、夏、秋、冬）ＦＯＲ年ＩＮ（１９９
６、１９９７））の代わりにカラムのリストを許可する。最適化プログラム３４
０及びコンパイラ３５０は、これらのオペレーションを、実行のための単一の方
式へと簡単に縮めることができる。

【００５０】前記ピボット・オペレーション（非ピボットではない）は、段階５４０におけ
る前記値カラムに対して、ＭＩＮ、ＳＵＭ、ＡＶＧ、さらにＣＯＵＮＴ等の従来
のＳＱＬ集約又は分類機能をサポートすることができる。その場合、グループ当
たりの単一の列への制限は引き上げることができる。当然、新しいカラムの種類
は、本来のそれとは異なるかもしれない。図４に基づいた以下の例は、集約を使
用した照会を示す：（ＳＥＬＥＣＴ年、四半期、売上ＦＲＯＭＮａｒｒｏｗ）．ＰＩＶＯＴ（ＳＵＭ（売上）ＦＯＲ四半期ＩＮ（春、夏、秋、冬）
この照会は、東部及び西部地域の売上を、各年に対する企業全体を表す単一の合
計へと統合する。分類機能が許可される変形においては、前記実行は、ピボット
・オペレーションが、さもなければピボットされたテーブルの異なる列における
重複一次キーを生成するであろうすべての場合に、ＳＵＭ等の特定の機能の暗黙
アプリケーションを特定することができる。前記集約は情報の詳細を失うので、
分類を有するピボットは、逆にすることはできない；標準ＳＱＬで分類された出
力は、同じ理由から逆にすることができない。この拡張によって非ピボットは真
の逆として機能することができないが、実施形態は、すべての本来の値を保存す
る内部「サイド・テーブル」を加えることによって、この機能を維持する。

【００５１】他の有力な拡張は、ピボット又は非ピボット・オペレーションにおける、リテ
ラル・カラム名のリストを、ＳＥＬＥＣＴ照会と置き換えるための機能を加える
。より複雑な処理が、補助照会を最初にランさせ、それから前記補助照会の結果
を使用して、ピボットされたカラムのリストを結合することに関与するであろう
；すなわち、前記補助照会は、図３に記載のブロック３４０及び３５０において
、交互配置されたコンパイル及び実行を要求する。前記実行は、ピボットされる
べき照会式を計算することを、結果に対する照会をランさせることと同様に要求
する。

【００５２】前記ピボット仕様は、ピボット・リストを完全に省略し、代わりにデフォルト
（default）照会を供給する。例えば、照会４２０からＩＮ（春、夏、秋、冬）文節を省略することで、ＳＥＬＥＣＴＤＩＳＴＩＮＣＴ四半期ＦＲＯＭ
Ｎａｒｒｏｗというデフォルト照会を代入することができる。これによって、
照会４２０は入力テーブルを２回参照することになるので、Ｃ＋＋における「ｔ
ｈｉｓ」という名前に類似して、オペレーションの入力テーブルに対して専用の
名前を導入すると便利である。オペレーション４２０は次のようになる：Ｎａｒｒｏｗ．ＰＩＶＯＴ（売上ＦＯＲＳＥＬＥＣＴＤＩＳＴＩＮＣ
Ｔ四半期ＦＲＯＭＩＮＰＵＴ）。

【００５３】ピボット・リストを要求する代わりに、前記非ピボット・オペレーションは、
オペレーションの入力においてピボットされたカラムを除くすべての仕様を許可
するであろう。上で修正された例４００において、逆オペレーションは図４に記
載の４４０のように：Ｗｉｄｅ．ＵＮＰＩＶＯＴ（売上ＦＯＲ四半期ＩＮ（春、夏、秋、冬
））か又は図４に記載の４６０のように：Ｗｉｄｅ．ＵＮＰＩＶＯＴ（売上ＯＶＥＲ（地域、年））と特定されることができる。この文脈でＯＶＥＲをサポートすることは、前記入力テーブルから前記一組のピ
ボットされたカラムを決定することを必要とし、及び上述のとおり、補助照会を
処理するための能力を要求する。ＩＮ及びＯＶＥＲ文節は結合されることができ
、一つ以上のカラムが分類カラムと同様にピボット・カラムになることを許可す
る。これが本出願の視点から意味をなすであろう状況は、各々の次の四半期のた
めに、第一の四半期以来の売上成長率の計算を許可するために、各出力列におけ
る春の売上を含む。

【００５４】いくつかのテーブルでは、一組のカラムは、いくぶん直交又は独立になること
ができる；例えば、「都市」及び「月」と名づけられたカラムは、すべての月に
対するすべての都市に対して、テーブル・エントリを有する傾向にある。他のカ
ラムの組は、階層的である−例えば「州」、「都市」、及び「店舗」カラムを有
する「場所」テーブル等−及びそれらのデータは希薄である；すなわち、ごく小
数の都市が複数の州に現れるであろうし、及び複数の店舗を有する都市はほとん
どないであろう。後半の場合において、２つのＩＮ文節を使用することは、ピボ
ット・オペレーションにおいて体裁を欠く構文及び意味になる。しかしながら、
単一のピボット・カラムの代わりにピボット・カラムのリストを使用することで
、この問題は改善される。「列値」のＡＮＳＩＳＱＬの概念は、この場合に適
切である。常にではないが、通常は、リテラル・カラム名のリストよりも、照会
を前記ピボット・リストとして特定する方が、より便利である。典型的な形式は
、Ｌｏｃａｔｉｏｎｓ．ＰＩＶＯＴ（売上量ＦＯＲ（都市、店舗）ＩＮ
（ＳＥＬＥＣＴ都市、店舗ＦＲＯＭアウトレット（outlets）））であろう。

【００５５】前記ピボット及び非ピボット・オペレーションはまた、図３に記載の照会プロ
セッサ３００の内部オペレーションにおいても、便利であろう。さらに、参照一
貫性の制約は、削除されたキー候補及び新しい外部キーのためだけに強化される
必要がある；ピボット／非ピボット又は類似の回転を使用することは、同じキー
値に関連する削除及び挿入項目を縮めることができ、及び潜在的に一貫性検査を
冗長であるとして排除する。さらに、大変に大きいＩＮ文節を有する従来の照会
においては、検索エンジンによって暗示的に呼び出された内部非ピボット・オペ
レーションは、多くのリテラル又はパラメータを含む単一の大変複雑な列を、カ
ラムとして、ループ、索引、統合及びハッシュ結合等の従来の結合方法、及びそ
れらの並行処理変形を使用して、データベース・テーブルに対抗することができ
る一組の列にマッピングすることができる。ピボット／非ピボット・オペレーシ
ョンの類似の内部引用は、ＩＮ文節にしばしば同等である、ＯＲ及びＵＮＩＯＮ
照会において有用であるかもしれない。

【００５６】最後に、前記ピボット及び非ピボット・オペレーションは、それらの拡張、最
適化及び実行方式とともに、関係データベース・システムの分野外のデータベー
ス管理システム及びデータ−操作ソフトウェアに含むことができる。例えば、代
数を基礎とした統計的−分析製品又は独立型分類パッケージは、これらの新しい
オペレーションが、外部及び内部の両方で有用であることがわかるかもしれない
。ＳＱＬ言語に関連して説明されたが、前記オペレーションは必ずしもＳＱＬに
統合され又は実際にホスト言語に統合される必要はない。

【図面の簡単な説明】

【図１】本発明に関するコンピュータネットワーク環境を示すブロック図である。

【図２】本発明を組込んだデータベース管理システムを示す図である。

【図３】図２のＤＢＭＳによって実行される機能のフローチャートである。

【図４】本発明によるピボット及び非ピボットのオペレーションの例を示す。

【図５】本発明によるピボットオペレーションのフローチャートである。

【図６】非ピボットオペレーションのフローチャートである。

【手続補正書】特許協力条約第３４条補正の翻訳文提出書

【提出日】平成１２年３月２７日（２０００．３．２７）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正内容】

【特許請求の範囲】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】０００８

【補正方法】変更

【補正内容】

【０００８】一部のスプレッドシート（ワークシート）のソフトウェアには、ユーザー選択
の矩形セルデータの置換えを、マトリクス代数「転置」オペレーションにおいて
行列要素αijをαjiに移動させるのと同じ方法でユーザーが行えるものがある。
例えば、マイクロソフト・エクセルのピボットテーブルでは、ユーザーは、矩形
セルを選択してテンポラリー・クリップボードにコピーし、オプションメニュー
から「移行」を選択した後に目標セルを指して「特殊な貼り付け」オペレーショ
ンを行う。更に、ユーザーは、マイクロソフト・オフイス等の互換性のあるアプ
リケーションプログラム一式を使って、マイクロソフト・アクセスのデータベー
ス構成要素であるデータベーステーブルからデータを選択し、そのデータを、矩
形スプレッドシート・セルのようなエクセル構成要素に対し単独オブジェクトと
して移してそのセルを置換え、次に、そのセルを置換えられたフォーマットの状
態のレコード集合体としてアクセスデータベースに転送することもできる。スプ
レッドシートにおけるピボットオペレーションについては、Ｊ．Ｃ．Ｎｅｓｓｉ
ｔｅｒの（ウインドウズのためのエクセル５の利用法、Ｑｕｅ社、１９９５年）
及びＢ．Ｄｏｓｍａｒｉａｓの「信頼性使用のためのマイクロソフト・エクセ
ル・ピボットテーブルの利用法」ＩＥＥＥ３４ｔｈ春季信頼性シンポジューム（
１９９６年月１８日）７９−８１頁に記載されている。

【手続補正３】

【補正対象書類名】明細書

【補正対象項目名】０００９

【補正方法】変更

【補正内容】

【０００９】この方法によるデータ項目の置換えは、下手なやり方でもあり機能的にも制限
されたものである。小規模のデータベースであっても、１つのクエリを実行する
ためだけに他のアプリケーションプログラムを呼出すのは無駄が多い。大規模な
データベースに関しては、置換えられたデータがメモリ内に残るという従来の要
件により、この方法を行うことは不可能となっている。ホストコンピュータを基
盤としたサーチエンジンを使用したクライエント・サーバ・アーキテクチャに関
しては、このオペレーションを行うために、スプレッドシート・プログラムに接
続する方法は存在しない。どのような環境下においても、スプレッドシートによ
る移行には必ず手作業が伴うため、クエリの内的部分をデータベースプログラム
内に構成することにより置換えを行うことはできない。このような外部オペレー
ションは、従来のデータベースのクエリプロセスや他のサーチエンジンにおける
最新式への再設定、再書換え、他の最適手順に関与することはできない。より概
念的レベルにおいては、スプレッドシートと関係型データベーステーブルとの基
本的な差異によって、望ましい置換え形式を採ることが妨げられている。例えば
、データベーステーブルの行即ちフィールドの名前は、テーブルそれ自体の一部
ではない。つまり、スプレッドシートにおける行の索引がスプレッドシート内で
はセル列にあるという点で、それらデータベーステーブルのフィールドの名前は
、テーブルのレコードにはならない。このように、スプレッドシートの列がテー
ブルのレコードとしてデータベースプログラムに戻される場合、スプレッドシー
トの矩形セルを置換えることにより、セルの行をデータベーステーブルにおける
行の名前に構成変更することはできない。一部の非関係データベースシステムには、スプレッドシート・ピボット・オペ
レーションと類似したオペレーションを持っているものがある。ＯＬＡＰ（オン
ライン分析処理）は、Ｕ．Ｆｌｏｈｒの「ウェブによるＯＬＡＰ」ＢＹＴＥ、１
９９７年9月、８１−８４頁；Ｂ.Ｌｉｎｄｈｏｎ他の「次元特集概要：ＯＬＡＰ
サーバ」ＤＡＴＡＭＡＴＩＯＮ、１９８５年５月、７０−７１頁；Ｍ．Ｆｒａｎ
ｋの「ＢｒｉｏＱｕｅｒｙ３．５」ＤＢＭＳＯＮＬＩＮＥ、１９９６年２月；
「ＯＬＡＰ及びＯＬＡＰサーバ定義」（ＯＬＡＰ委員会、１９９５年）；及びＣ
．Ｂ．Ｄａｒｌｉｎｇの「ＯＬＡＰＢＯＸ考」ＤＡＴＡＭＡＴＩＯＮ、１９９６
年４月１５日、８８−９２頁に言及されているように、多次元「立方体」データ
に関する回転オペレーションを実行することができる。

【手続補正４】

【補正対象書類名】明細書

【補正対象項目名】００３７

【補正方法】変更

【補正内容】

【００３７】非ピボット・オペレーションは、ピボット・オペレーションの逆であり、及び
＜テーブル＿式｜照会＿式＞．ＵＮＰＩＶＯＴ（＜値＿カラム＞ＦＯＲ＜
ピボット＿カラム＞ＩＮ（＜カラム＿リスト＞）として形式的に定義される
。前記用語の意味は、前記ピボット・オペレーションに対するものと同じである
。同じ仕様を有するピボット及び非ピボット・オペレーションを入力テーブルに
適用することで、前記入力テーブルをその本来の状態に戻す。図４に記載の例に
おいて、前記非ピボット・オペレーションをピボットされたテーブル４３０に適
用することで、テーブル４１０を元に戻す；売上４１２及び四半期４１１と名づ
けられた前記２つのカラムは、カラム４３１乃至４３４に取って代わる。他のデータベースシステムのオペレーションは、Ｍ．Ｇｙｓｓｃｎｓ他の「ク
エリと再構築の実例としてのテーブル」ＰＲＯＣＥＥＤＩＮＧＳ，１９９６年、
ＡＣＭＳＩＧＭＯＤＩＮＴＥＬ、「データ管理のコンフィギュレーション」
Ｍｏｎｔｅａｌ、Ｑｕｏ、カナダ、１９９６年６月３−６日、９３−１０３頁に
述べられているグループ化/分割や合併/決裂の対のような相互の反転として考え
ることができる。ピボット/非ピボットも同様に相互の反転である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者アルガージェフアメリカ合衆国ワシントン州 98053 レッドモンドノースイーストフィフティサードプレイス 24066 Ｆターム(参考） 5B075 NK54 NR03 NR20 QR00 QT06 5B082 GA03 GA08 【要約の続き】び出されてもよい。

Claims

【特許請求の範囲】

【請求項１】デジタルコンピュータ上の関係型データベース管理システム
内に出力テーブルを形成するために、入力テーブルからデータをピボット化する
方法であって、前記入力テーブルを定義する段階、前記入力テーブルのピボット行を定義する段階、前記ピボット行からデータ項目のピボットリストを定義する段階、前記入力テーブルの値行を定義する段階、及び前記出力テーブルを構成するために、前記ピボットリスト内のデータ項目に基
づき、前記ピボット行について前記入力テーブルを置換える段階を含むことを特
徴とする方法。
【請求項２】前記入力テーブルの少なくとも１つのグループ化する行を定
義する段階、及び前記１つ又はそれ以上のグループ化する行内のデータ項目の均等値に従って、
前記出力テーブルの列をグループ化する段階を更に含むことを特徴とする請求項
１に記載の方法。
【請求項３】前記置換える段階は、複数の遠隔の顧客場所に位置するユー
ザーに応答する中央サーバにおいて生じ、前記定義する段階は、前記ユーザーの
1人によって起こされることを特徴とする請求項１に記載の方法。
【請求項４】前記定義する段階の各々は、前記ピボット方法を明示的オペ
レーションとして含まないユーザーからのクエリを最適化する段階の一部として
、前記中央サーバにおけるサーチエンジンに起こることを特徴とする請求項１に
記載の方法。
【請求項５】複数の列及び行として編成されたデータ値のアレイを各々有
し、前記データ値から切離されるとともに前記行の各々に関連付けられた複数の
行の名前を各々有する、電子データプロセッサ内に記憶された関係型データベー
ス入力テーブル及び出力テーブルにおいて、前記入力テーブルから出力テーブル
にデータを構成変更する方法において、ピボット行として、前記入力テーブルの第1行の名前を選択する段階、値行として、前記入力テーブルの第２行の名前を選択する段階、前記データプロセッサ内の入力テーブルにアクセスする段階、前記ピボット行内のデータ値のセットを、前記出力テーブル内の複数のピボッ
ト化された行に関連付けられた各々の行名に変換する段階、及び前記ピボット行内のデータ値セットの特定の1つと同じ前記入力テーブルの列に位置する前記値行内の各データ値について、前記特定の１つのデータ値を、前
記出力テーブルのピボット化された行の特定の1つに置く段階を含み、前記特定の１つのピボット化された行は、前記ピボット行内の前記特定の１つのデータ値
に対応する名前を持ち、更に前記データプロセッサ内に前記出力テーブルを記憶する段階を含むことを特徴
とする方法。
【請求項６】ピボットリストとして、前記ピボット行内のデータ値セット
の特定の１つを選択する段階を更に含み、前記変換する段階は、前記ピボットリ
スト内のこれらのデータ値のみを前記行名に変換することを特徴とする請求項５
に記載の方法。
【請求項７】前記変換する段階は、前記ピボット行内のＮＵＬＬデータ値
を有する前記入力テーブル内の列のいずれも、列の名前に変換しないことを特徴
とする請求項６に記載の方法。
【請求項８】前記入力テーブルは、前記ピボット行及び値行以外の他の行
を含み、前記他の行の少なくとも一部の行内のデータ項目の均等値により、前記
出力テーブルの列をグループ化する段階を更に含むことを特徴とする請求項５に
記載の方法。
【請求項９】前記グループ化する段階は、前記他の行の全ての行内の前記
データ項目の均等値により、前記出力テーブルの列をグループ化することを特徴
とする請求項８に記載の方法。
【請求項１０】デジタルコンピュータ上の関係型データベース管理システ
ム内に非ピボットテーブルを形成するために、ピボットテーブルからのデータを
非ピボット化する方法であって、前記ピボット化テーブルを定義する段階、前記非ピボット化テーブルに関するピボット行名を定義する段階、前記ピボット化テーブルの行のピボットリストを定義する段階、前記非ピボット化テーブルに関する値行名を定義する段階、前記非ピボット化テーブル内にピボット行及び値行を構成する段階、及び前記非ピボット化テーブルのピボット行内のデータ項目として前記ピボットリ
スト行の名前を置くとともに、前記ピボットリスト行内のデータ項目を前記非ピ
ボット化テーブルの値行の列に置くために、前記ピボットリスト内の行について
前記ピボット化テーブルを置換える段階を含むことを特徴とする方法。
【請求項１１】前記ピボット化テーブルの少なくとも１つのグループ化す
る行を定義する段階、及び前記１つ又はそれ以上のグループ化する行内のデータ項目の均等値に従って、
前記非ピボット化テーブルの列をグループ化する段階を更に含むことを特徴とす
る請求項１０に記載の方法。
【請求項１２】前記置換える段階は、複数の遠隔の顧客場所に位置するユ
ーザーに応答する中央サーバにおいて生じ、前記定義する段階は、前記ユーザー
の1人によって起こされることを特徴とする請求項１０に記載の方法。
【請求項１３】前記定義する段階は、前記ピボット方法を明示的オペレー
ションとして含まないユーザーからのクエリを最適化する段階の一部として、前
記中央サーバにおけるサーチエンジンに起こることを特徴とする請求項１０に記
載の方法。
【請求項１４】複数の列及び行として編成されたデータ値のアレイを各々
有し、且つ前記データ値から切離されるとともに前記行の各々に関連付けられた
複数の行名を各々有する、電子データプロセッサ内に記憶された関係型データベ
ースピボット化テーブル及び非ピボット化テーブルにおいて、前記ピボット化テ
ーブルから非ピボット化テーブルにデータを構成変更する方法において、ピボット行の名前として、名前を選択する段階、ピボットリストとして、前記ピボット化テーブル内の前記行の複数の名前を選
択する段階、値行の前記名前として、名前を選択する段階、前記データプロセッサ内のピボット化テーブルにアクセスする段階、前記非ピボット化テーブル内に、前記ピボット行名として選択された名前を有
するピボット行を生成するする段階、前記ピボットリスト内の行名を前記ピボット行内のデータ値に変換する段階、前記値行に関して選択された名前を有する前記非ピボット化テーブル内の値行
を生成する段階、前記ピボットリスト内の前記ピボット化テーブル行の各特定行内の各特定デー
タ値について、前記特定データ値を、前記ピボット化テーブルの前記特定行に対
応する前記ピボット行内のデータ値も含む列内の前記非ピボット化テーブルの値
行に置く段階、及び前記データプロセッサ内に前記非ピボット化テーブルを記憶する段階を含むこ
とを特徴とする方法。
【請求項１５】前記ピボット化テーブルは、前記ピボットリスト以外の他
の行を含み、前記他の行の少なくとも一部の行内のデータ項目の均等値により、
前記非ピボット化テーブルの列をグループ化する段階を更に含むことを特徴とす
る請求項１４に記載の方法。
【請求項１６】前記グループ化する段階は、前記他の行の全ての行内の前
記データ項目の均等値により、前記非ピボット化テーブルの列をグループ化する
ことを特徴とする請求項１５に記載の方法。
【請求項１７】多数の顧客と、関係型データベース内の入力テーブル、前記入力テーブル内のピボット行（４１１）の名前と前記入力テーブル内の値
行の名前、及び前記ピボット行内のデータ値のピボットリストを指定するピボッ
トオペレーションを含む前記顧客の1人からのクエリを構文解析し最適化し実行するためのサーチエンジンとを含み、前記サーチエンジンは、ピボット化出力テ
ーブルを構成するために、前記ピボットリスト内のデータ項目に基づいて、前記
ピボット行について前記入力テーブルの値行内のデータ項目を置換えることを特
徴とする関係型データベース。
【請求項１８】前記サーチエンジンは、中央サーバにあり、更に前記顧客
は、前記サーバから離れた複数の場所に物理的に位置することを特徴とする請求
項１７に記載のシステム。
【請求項１９】前記最適化モジュールは、前記ピボットオペレーションを
含むクエリを最適化することを特徴とする請求項１７に記載のシステム。
【請求項２０】前記1人の顧客からのクエリは、多数のピボット化行について前記ピボット化テーブル内のデータ項目を置換えることによって、前記ピボ
ット化テーブルにおける前記ピボットオペレーションの効力を反転するために非
ピボットテーブルを指定する非ピボットオペレーションを含むことを特徴とする
請求項１７に記載のシステム。
【請求項２１】前記ピボット化行内のデータ項目は、前記非ピボット化テ
ーブルの値行に置かれることを特徴とする請求項２０に記載のシステム。
【請求項２２】入力テーブル、ピボット行、及び値行を含むピボット仕様
に従って列及び行内に置かれたデータ値を有する関係型データベース内のピボッ
ト化テーブルであって、前記ピボット行内のデータ値の識別可能な１つのデータ値に対応する行名を各
々有する複数のピボット化行、及び前記値行からの複数のデータ値を各々含む複数の列を含み、前記複数の列の１
つの列内のデータ項目の各々は、データ値として前記１つのピボット化行の名前
を含む前記入力テーブルの列に対応する名前を持つ前記ピボット化行の１つの行
内に位置していることを特徴とするテーブル。
【請求項２３】前記仕様は、ピボット値のピボットリストを更に含み、前
記出力テーブルのピボット化行は、前記ピボットリストに載せられた前記ピボッ
ト行内のデータ値に対応する行から成ることを特徴とする請求項２２に記載のテ
ーブル。
【請求項２４】前記入力テーブルは、ピボット行及び値行以外に、他の行
を含み、前記出力テーブルは、前記入力テーブルの他の行からのデータ値を含む
グループ行を含むことを特徴とする請求項２２に記載のテーブル。
【請求項２５】前記出力テーブルの列は、前記グループ行のデータ項目の
均等値によりグループ化されることを特徴とする請求項２４に記載のテーブル。
【請求項２６】前記入力テーブルは前記他の行を複数含み、前記複数の他
の行は、前記出力テーブル内の切離されたグループ行を作り出すことを特徴とす
る請求項２５に記載のテーブル。
【請求項２７】前記テーブルは、記憶媒体に記憶されていることを特徴と
する請求項２２に記載のテーブル。
【請求項２８】ピボット入力テーブル、ピボット行、ピボットリスト及び
値行を含むピボット仕様に従って列及び行内に置かれたデータ値を有する関係型
データベース内の非ピボット化テーブルであって、前記ピボット行に対応する名前を有するピボット行を含み、その列には前記ピ
ボットリストに載せられたピボット化テーブル行の名前から引出されたデータ項
目が含まれ、更に前記仕様内の前記値行から引出された名前を有する値を含み、前記値行の各特
定列は、前記非ピボットテーブルの同じ特定列内のデータ項目に名前があるピボ
ット化行の1つの行内のデータ項目から引出されたデータ項目を含むことを特徴とするテーブル。
【請求項２９】前記ピボット化テーブルは、前記ピボット化行以外に、少
なくとも1つの他の行を含むことを特徴とする請求項２８に記載のテーブル。
【請求項３０】前記非ピボットテーブルの列は、前記少なくとも１つの他
の行の均等値によりグループ化されることを特徴とする請求項２９に記載のテー
ブル。
【請求項３１】前記テーブルは、記憶媒体に記憶されていることを特徴と
する請求項２８に記載のテーブル。
【請求項３２】入力テーブル、前記入力テーブルのピボット行、前記ピボ
ット行からのデータ項目のピボットリスト、及び前記入力テーブルの値行を定義
する仕様を受入れる段階、及び出力テーブルを構成するために、前記ピボットリスト内のデータ項目に基づい
て前記ピボット行について前記入力テーブルを置換える段階を含む各段階を、好
適にプログラムされたコンピュータに実行させるようにするために記憶されたプ
ログラムを有することを特徴とするデータ記憶媒体。
【請求項３３】前記プログラムされたコンピュータは、前記入力テーブルの少なくとも１つのグループ行を定義する段階、及び前記少なくとも１つのグループ行内のデータ項目の均等値に従って、前記出力
テーブルの列をグループ化する更なる段階を実行することを特徴とする請求項３
２に記載のデータ記憶媒体。
【請求項３４】ピボット化テーブル、前記ピボット化テーブルからの行の
ピボットリスト、ピボット行名、及び非ピボット化テーブルに関する値行名を定
義する段階、前記非ピボットテーブル内にピボット行及び値行を構成する段階、及び前記非ピボット化テーブルの前記ピボット行内のデータ値として前記ピボット
リスト行の名前を置くとともに、前記ピボットリスト行内のデータ項目を前記非
ピボット化テーブルの値行の列に置くために、前記ピボットリスト内の行につい
て前記ピボット化テーブルを置換える段階を含む各段階を、好適にプログラムさ
れたコンピュータに実行させるようにするために記憶されたプログラムを有する
ことを特徴とするデータ記憶媒体。
【請求項３５】前記プログラムされたコンピュータは、前記ピボット化テーブルの少なくとも１つのグループ行を定義する段階、及び前記少なくとも１つのグループ行内のデータ項目の均等値に従って、前記非ピ
ボット化テーブルの列をグループ化する更なる段階を実行することを特徴とする
請求項３４に記載のデータ記憶媒体。