JP2004520633A - 属性又はキー値を選択的に利用することによりクエリ生成を最適化する方法と装置 - Google Patents
属性又はキー値を選択的に利用することによりクエリ生成を最適化する方法と装置 Download PDFInfo
- Publication number
- JP2004520633A JP2004520633A JP2000581554A JP2000581554A JP2004520633A JP 2004520633 A JP2004520633 A JP 2004520633A JP 2000581554 A JP2000581554 A JP 2000581554A JP 2000581554 A JP2000581554 A JP 2000581554A JP 2004520633 A JP2004520633 A JP 2004520633A
- Authority
- JP
- Japan
- Prior art keywords
- dimension
- query
- key
- value
- attribute
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 13
- 238000013479 data entry Methods 0.000 claims 4
- 230000001419 dependent effect Effects 0.000 claims 1
- 101150086656 dim1 gene Proteins 0.000 description 5
- 238000005259 measurement Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 150000001875 compounds Chemical class 0.000 description 3
- 238000005192 partition Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
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
-
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24549—Run-time optimisation
-
- 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/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- 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/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
-
- 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/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99935—Query augmenting and refining, e.g. inexact access
-
- 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/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
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)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
データベース（６）のデータの２以上の組を結合する方法が提供され、ファクトデータの中の特定のディメンション（１２）が強制されたディメンションとして指定され、各強制されたディメンションに対して１組のエントリがファクトデータにおいて生成され、その時強制されたディメンション以外の全てのディメンションで同一のキー値を伴い、そして各々はそのディメンションに対するファクトデータの中に存在する値の組の異なった要素を伴っている。このことは、少なくとも１のエントリが、強制されたディメンション以外の他のディメンションの中のキー値の同一の組を伴うファクトデータに存在する場合に、しかもその場合に限り、成り立つ。
Description
【０００１】
【発明の属する技術分野】
本発明は、データベースのデータクエリ処理に関し、より詳しくは、効率的にクエリを実行するために適切なクエリパラメータを選ぶ方法に関する。
【０００２】
【従来の技術】
データベースは、一般的にある性質のインスタンスデータを表わす１以上のファクトテーブルに、ファクトテーブル中のデータに対する属性を画定するディメンションデーブルに沿って、データを蓄える。図１に示されるようにファクトテーブルは、該当するインスタンスに関連付けられた特定のディメンションの要素をそれぞれ表現するカラムと、その特定のインスタンスに関連するデータを含む１以上の測定カラムを有する。しばしば測定値は、ファクトテーブルのレコードがまとめられる場合、何らかの方法で集められ得る値である。例えば、エントリーは合計されるかあるいは平均化される。しかし、これはそのようなケースではなく、ファクトテーブルの中のある測定カラムの「測定データ」は、任意の文字ストリングや他の種類の集められることができない値である。
【０００３】
【発明が解決しようとする課題】
本発明は、どんな種類のファクトテーブルにも、それが属性を有する１以上のディメンションに関連する限り、作用する。
【０００４】
【課題を解決するための手段】
ディメンションはクラス内の限定されたエンティティの組を表現し、それぞれは共通の方法によって分類され得る１以上の属性を伴う。一つのディメンションは、ディメンションテーブルの中において通常表現されて、１以上のカラムをテーブルにおいて有してディメンションにおける各エンティティを識別しており、それらはキー値又は値として知られている。キー値はしばしばディメンションのエンティティに対してそれらを一意的に識別するために与えられている任意の識別子である。他のテーブルのカラムはおそらくキーカラムの１つを含んでおり、それぞれのエンティティの異なる属性を提供する。これらの属性値は、異なったレベルにおいてディメンションテーブルのエンティティを集め、そして、それらの属性に従ってファクトテーブルからデータを抽出したり集めたりする為に使用可能である。
【０００５】
スペース効率の為と、データベースにおける不調和に至り得る冗長さを避ける為に、各々のディメンションに対するキー値のみが、ファクトテーブルに記憶される。より効率的な場合は、該当するディメンションのキー値と１対１な対応を有する内的な表現は、ファクトテーブルに記憶可能であることは注意すべきである。これらはユーザには決して見えない。この種の場合、内的な表現はこの議論の為のキー値であるとみなすことができる。
【０００６】
本願出願のクエリ例は、ＳＱＬ言語によって与えられ、その理由はこの言語が現在最も普及しているクエリ言語であるからである。しかし、ここで述べられる本願は、他のクエリ言語によって等しく効果的に表現され得ることは明らかである。
ユーザーによってリクエストされた属性値を使ってデータベースの中のデータに対してクエリが実行される場合、ディメンションテーブルはクエリの中に含まれなければならず、そのことは以下の例に示される。
【０００７】
【表１】
【０００８】
この種のクエリにおいて、クエリで指定されるテーブルは、それぞれのテーブルのどんな共通なフィールドをも互いに結合する。上記の実例において、ｋｅｙ１フィールドはｄｉｍ１テーブルとファクトテーブルの両方に共通である。ｋｅｙ２フィールドはｄｉｍ２テーブルとファクトテーブルの両方に共通である。ｋｅｙ３フィールドは、ｄｉｍ３テーブルとファクトテーブルの両方に共通である。
【０００９】
この種の結合を利用する事によって、エントリーは出力テーブルにおいて生成されて、結合フィールドが各テーブルにおいて同一である２つの結合テーブルの両方のエントリーのすべての組み合わせに対応する。結合フィールドは、出力結合テーブルに一度現れるだけである。例えば、図２Ａと２Ｂに示される２つのテーブルを結合するとその結果、図２Ｃに示される出力テーブルが与えられる。
【００１０】
しかし、もしも属性値の初期マッピングがそれぞれのディメンションで選択されて、そのディメンションのキー値の上にマッピングされる場合、ディメンションテーブルをファクトテーブルとクエリにおいて結合する必要はなく、なぜなら全ての必要な情報はファクトテーブルにあるからである。例えば、クエリは次のように示される。
【００１１】
【表２】
【００１２】
データベースがクエリを扱う方法に依存しているので、これはしばしば等価属性論理クエリよりもはるかに能率的であり、その理由はディメンションテーブルがクエリの中に含まれる必要がないからである。さらにデータベースエンジンは、多様な最適化による属性よりもはるかに能率的にキー値を処理可能である。
【００１３】
データベースは、ファクトテーブルを例えばそれぞれのディメンションのキー値によってインデックス付けることによって最適化可能である。適切なファクトデータは、結果として生じるデータセットを含んで、インデックスのそれぞれのキーに対するエントリーを通してスキャンする事によって非常に早く発見可能であり、その理由は特定のキーに関連するインデックスは、連続的に配列されるからである。
【００１４】
もしそのようなインデックスに基礎をおいた構成がデータベースに使用されるなら、以下の種類のクエリはしばしば、キー値上のクエリ処理の時でさえ、より有利である。
【００１５】
【表３】
【００１６】
現行のデータベースクエリ処理ツールによって用いられるどんなクエリ論理であるかに関わらず、それらは同じリクエストから適切なＳＱＬクエリへの変換を用い、そして、選択されたクエリ論理の使用をサーチされるエントリー数に無関係である。例えば、ある状況においては、特にディメンションにおいてより高いレベルであるとき、選択することによって選択基準に適合するディメンションテーブルからの多数のレコードを、結果としてもたらす。例えば、市場におけるすべてのミューチュアルファンドの全ての在庫資金が求められるかもしれない。実際、選択基準に一致している何百ものディメンションエントリがあるかもしれない。もしも、データベースクエリ処理ツールが自動的に設定されて、選択ディメンション属性エントリーがファンドディメンションのキー値に変換されるならば、そのディメンションは選択基準に一致するキー値を見つけようとしてサーチするだろう。該当するエントリーは、「ＩＮ」リストを使うクエリに上記のように加えられる。キー値が非常に大きくなる場合は問題が起きる。多くのデータベースシステムは、単一の「ＩＮ」リストにおいて値のナンバの制限を課しており、クエリツールはそれゆえにクエリを多くのクエリに分散し、データベースにおいてサーチする。更に、ディメンションがインデックス付けされていなかったとしても、ファクトテーブルだけを用いてキー値の重要な数字をクエリ処理する事は、少ない属性値をクエリ処理してそして、ディメンションをクエリに導入するよりも、長い時間がかかる。例えば、データベースエンジンが属性値に関連するディメンションテーブルの中から見つけ出して、それが一致しているかを見る事は、キー値が一致しているかどうかを見ることと同じ位に迅速である。もしも、等価クエリにおいて、属性値のナンバよりもキー値がはるかに多く存在している場合、関連するディメンションにおける属性値を見つけ出す事は、それらの一つが一致するかどうか全てのキー値を見てチェックするよりも、殆ど確実に早い。
【００１７】
クエリツールは、クエリ処理された実際の属性に依存している選択可能なクエリ構造から選ぶ事が出来るように要求される。
本発明は１以上のディメンションからの属性を含むデータリクエストからクエリを生成する方法を提供し、属性に対応するキー値は確かめられ、クエリを実行する為に必要な属性及びキー値の個数に依存するクエリにおけるキー値ロジックあるいは属性ロジックのいずれを使用すべきかを決定する為に用いられる。
【００１８】
【発明の実施の形態】
本発明による実施例は図３から図４に関連して、述べられる。
図３に示されるように、クエリジェネレータ２０は、アプリケーションサーバ２上のオブジェクトとして提供されている。クエリジェネレータは、外部リクエストを受け入れて、そこからＳＱＬクエリを生成する。これらのＳＱＬクエリは、データベース６からリクエストされたデータを検索するデータベースエンジン４に送られる。戻ったデータはその後データベースエンジンからアプリケーションサーバへと送り返されて、リクエスタ（ｒｅｑｕｅｓｔｏｒ）に送り返されるか、処理されて他のところ、例えばディスプレイサーバ１０へと送られる。
【００１９】
アプリケーションサーバは又、検索されることになっているファクトデータに関するデータベースに蓄えられたディメンションのレプリカ１２を記憶する。１以上の属性を含むリクエストが、クエリジェネレータによって受容されるとき、クエリジェネレータはディメンションエントリーを通してサーチし、そして、要求された全てのキー値を識別する。これはデータベースサーバへのクエリを使用することにより可能であるが、しかし、ずっと能率が悪い。
【００２０】
クエリジェネレータ２０は、それから以下の論理を用いてクエリ生成の方法を決定し、このことは図４のフローチャートに表現されている。
各ディメンションに対して、キー値のナンバが特定の経験的に決定されたしきい値以下である場合、単にキー値をファクトテーブルの中の値と比較してクエリの結果を得るのがより効率的であるとみなされる。この出願人によって具現化された実施例のシステムにとって、このしきい値の理想的な値は３０であると分かった。この場合、生成されたクエリはディメンションを含まず、単にファクトデータ上に作成される（このディメンションに関しては「クエリなし」と呼ばれ、ディメンションがリクエストされていないからである。）例えば、以下のクエリが生成される。
【００２１】
【表４】
【００２２】
しかし、キーのナンバが特定の予め定められたしきい値を越える場合は、生成されたクエリは、ファクトテーブルのディメンションへのインデックスがあるかないかによって変化する。
上に示されたように、ディメンションがインデックスを付けられる場合には、そのディメンションからのキー値は、非常に迅速にそのキー値を取り入れているファクトテーブルの適切なエントリーの上へとマッピングされる。
【００２３】
ディメンションキーがインデックスを付けられる場合、比較がなされて実行されて、クエリの中に現れるキー値のナンバが、ある一定の予め定められた定数Ａの倍数された属性値のナンバを越えるかどうかを見て、又経験的に進行する。この出願人によって具現化された実施例のシステムにとって、このしきい値の理想的な値は３０であると分かっており、しかし、この値は上述の議論されたしきい値に関連していない事が注目されるべきである。
【００２４】
キー値のナンバがこの値を越える場合、属性論理はより効果的となり、そして、属性クエリは生成される。例えば、「結合を有する」クエリは、以下の項を含んで生成される。「結合を有する」という言葉は、図２Ａ−２Ｃに関連して議論されたように、該当するディメンションテーブルとファクトテーブルとの間に結合を実行する事実に関している。クエリに基礎を置く全ての属性は、そのディメンションに関して「結合を有する」クエリであるという事が注目されるべきであり、何故ならば、ディメンションテーブルに対するリソースなしでは、属性値は確認される事が出来ないからである。
【００２５】
【表５】
【００２６】
しかし、キー値のナンバが属性値の定数Ａ倍をかけられたナンバを越えない場合は、「結合を有する」クエリに基礎をおいたキー値は、クエリにディメンションを含んで生成され、データベースエンジンの最適化されたインデックス処理を用いる。クエリは以下の項を含む。
【００２７】
【表６】
【００２８】
該当するディメンションがインデックスが付けられない場合は、例えあったとしても、キー値を使用する利点がより少ない。例えば、データベースエンジンが関連するディメンションテーブルの属性値を探し出してそれが一致するかをチェックする速さはそれが、キー値が一致するかどうかを見るくらいに速い。それゆえ、この場合においては、経験的な係数を確立する長さに向かうよりはむしろ、キー値のナンバと属性値ナンバとの単純な比較がなされる。しかし、この種の係数は適切であるなら、データベースエンジンに依存して使用され得る。
【００２９】
キー値の値がそのディメンションに対するクエリにおいて用いられる属性値のナンバよりも大きい場合は、「結合を有する」属性クエリは、クエリの中のそのディメンションに対して用いられる。一方、「結合を持たない」クエリキーはそのディメンションに対して用いられ、サーチにおいてディメンションを含む利点が、それがインデックスを付けられていないが故に、存在しない。
【００３０】
この選択算法はあらゆるディメンションに対して繰り返され、クエリは適切に生成されてデータベースクエリエンジンに転送される。
勿論、各々のディメンションの異なったクエリの性質によって、異なった結合は各々のディメンションに生成される。あるディメンションはクエリの中に含まれ、他のものは、含まれない。さらに、いくつかのディメンションは、属性論理を含み、他のものは含まない。例えば、以下の完全クエリは生成されて第１ディメンション及び第３ディメンションをそのクエリに含み、第１のものはキー値論理を使用し、第２のものは属性値論理を使用する。
【００３１】
【表７】
【００３２】
特定のリクエストは、これまでに記載されている場合よりも、より複雑である。例えば、「複式保持」リクエストは、ユーザーが複数の分離された選択（「保持」）をディメンションから作るときに起きる。この場合生成されるクエリは、句（ｃｌａｕｓｅ）をこの状況に対してモデル化する際にＯＲ論理を用いる必要がある。例えば、ユーザーがディメンションｄｉｍ１から選択するときに、複式「保持」を選ぶ場合を仮定する。第１保持は、属性ａｔｔｒ１とａｔｔｒ２とを含み、一方、第２保持は属性ａｔｔｒ３とａｔｔｒ４とを含む。生成されたクエリは以下のようでなければならない。
【００３３】
【表８】
【００３４】
この実施例によれば、この種類のクエリに関して、属性に基礎を置いたクエリに参照される各属性は、上記の算法（アルゴリズム）によって属性として計数される。キー値を使用する等価クエリは、最初に説明したのと同じフォーマットであり、単純な「ＩＮ」リストを有して、そして、キー値のナンバを確立すべき複雑さをそれゆえに加えない。
【００３５】
ユーザが、「ベース」計算（すなわちシェアのような「ｓｔｈ」）を含む測定を選ぶときは、しかしより複雑なシナリオが発生する。これは一般的に、与えられたディメンションからの「舞台裏の」追加的選択を必要とする。キー論理は、ディメンションのためのキーリストの追加的なキー値によってこの状況を解決する。属性論理は、複式「保持」に関連する構文の一番上の追加的ＯＲを実行する必要がある。（上の実例からの複式「保持」の一番上において）ユーザーがディメンションｄｉｍ１の追加的な選択を必要とする「ベース」計算を選択すると仮定し、それを今、属性ａｔｔｒ５からとしよう。クエリは以下のように読み取れる。
【００３６】
【表９】
【００３７】
この種の状況は、「複式保持」シナリオに似た方法で、処理される。
スター結合オプションは、属性論理オプションと、インデックス付けされたディメンションに基づいたスター結合を使用するある種のディメンションと、そして、標準属性論理を用いるある種のディメンションと、に連動して用いられることが注意されるべきである。単純な属性論理の場合がディメンションｄｉｍ１に用いられると仮定すれば、クエリは以下のように見られる。
【００３８】
【表１０】
【００３９】
この実施例のシステムの場合、ユーザプロファイルはユーザに対して戻されるデータをサブセット可能にする。ユーザはユーザだけが見る特権を与えられているそれらの記録に対してのみアクセスを有する。ベースはそれを実現するためにフィルタリング機構を使用する。属性論理の観点から、ユーザプロファイルは、ユーザがアクセスすることができるデータのサブセットを判定するディメンション選択の組である。ディメンションｄｉｍ１の為のユーザプロファイルが、ユーザは与えられた値のリストに属性ａｔｔｒＫ値が存在するそれらのレコードに対してのみアクセスし得ているように規定すると仮定すると、その属性論理によって生成されるクエリは以下のように見られる。
【００４０】
【表１１】
【００４１】
述べられた属性値は本発明のこの実施例の算法では単一属性値として扱われる。
属性論理は分割されたファクトセットによって打撃を受けない。物理的パーティションの場合、それぞれのパーティションは集約（ａｇｇｒｅｇａｔｅ）テーブルを用いる事によって画定される。一般的に、クエリは記載されるロジックを使用するそれぞれのパーティションに対して発行される。
【００４２】
本発明の好適な実施例が例示され記載されているが、当業者においては、変更と修正は本発明のより広い面から逸脱する事なく、為され得る事が理解されるべきである。本発明の多様な特徴は、請求項に記載されている。
【図面の簡単な説明】
【図１】例として、３つの生成関連テーブル及び対応するファクトテーブルを示している。
【図２Ａ】例としてのテーブルを示す。
【図２Ｂ】例としてのテーブルを示す。
【図２Ｃ】図２Ａ及び２Ｂに示されている２つのテーブルの結合を示す。
【図３】本発明の第１実施例によるシステム構成要素を示す。
【図４】本発明の第１実施例に従う選択算法を表現しているフローチャートである。
【符号の説明】
２ アプリケーションサーバ
６ データベース
１０ ディスプレイサーバ
１２ ディメンション
２０ クエリジェネレータ
【発明の属する技術分野】
本発明は、データベースのデータクエリ処理に関し、より詳しくは、効率的にクエリを実行するために適切なクエリパラメータを選ぶ方法に関する。
【０００２】
【従来の技術】
データベースは、一般的にある性質のインスタンスデータを表わす１以上のファクトテーブルに、ファクトテーブル中のデータに対する属性を画定するディメンションデーブルに沿って、データを蓄える。図１に示されるようにファクトテーブルは、該当するインスタンスに関連付けられた特定のディメンションの要素をそれぞれ表現するカラムと、その特定のインスタンスに関連するデータを含む１以上の測定カラムを有する。しばしば測定値は、ファクトテーブルのレコードがまとめられる場合、何らかの方法で集められ得る値である。例えば、エントリーは合計されるかあるいは平均化される。しかし、これはそのようなケースではなく、ファクトテーブルの中のある測定カラムの「測定データ」は、任意の文字ストリングや他の種類の集められることができない値である。
【０００３】
【発明が解決しようとする課題】
本発明は、どんな種類のファクトテーブルにも、それが属性を有する１以上のディメンションに関連する限り、作用する。
【０００４】
【課題を解決するための手段】
ディメンションはクラス内の限定されたエンティティの組を表現し、それぞれは共通の方法によって分類され得る１以上の属性を伴う。一つのディメンションは、ディメンションテーブルの中において通常表現されて、１以上のカラムをテーブルにおいて有してディメンションにおける各エンティティを識別しており、それらはキー値又は値として知られている。キー値はしばしばディメンションのエンティティに対してそれらを一意的に識別するために与えられている任意の識別子である。他のテーブルのカラムはおそらくキーカラムの１つを含んでおり、それぞれのエンティティの異なる属性を提供する。これらの属性値は、異なったレベルにおいてディメンションテーブルのエンティティを集め、そして、それらの属性に従ってファクトテーブルからデータを抽出したり集めたりする為に使用可能である。
【０００５】
スペース効率の為と、データベースにおける不調和に至り得る冗長さを避ける為に、各々のディメンションに対するキー値のみが、ファクトテーブルに記憶される。より効率的な場合は、該当するディメンションのキー値と１対１な対応を有する内的な表現は、ファクトテーブルに記憶可能であることは注意すべきである。これらはユーザには決して見えない。この種の場合、内的な表現はこの議論の為のキー値であるとみなすことができる。
【０００６】
本願出願のクエリ例は、ＳＱＬ言語によって与えられ、その理由はこの言語が現在最も普及しているクエリ言語であるからである。しかし、ここで述べられる本願は、他のクエリ言語によって等しく効果的に表現され得ることは明らかである。
ユーザーによってリクエストされた属性値を使ってデータベースの中のデータに対してクエリが実行される場合、ディメンションテーブルはクエリの中に含まれなければならず、そのことは以下の例に示される。
【０００７】
【表１】
この種のクエリにおいて、クエリで指定されるテーブルは、それぞれのテーブルのどんな共通なフィールドをも互いに結合する。上記の実例において、ｋｅｙ１フィールドはｄｉｍ１テーブルとファクトテーブルの両方に共通である。ｋｅｙ２フィールドはｄｉｍ２テーブルとファクトテーブルの両方に共通である。ｋｅｙ３フィールドは、ｄｉｍ３テーブルとファクトテーブルの両方に共通である。
【０００９】
この種の結合を利用する事によって、エントリーは出力テーブルにおいて生成されて、結合フィールドが各テーブルにおいて同一である２つの結合テーブルの両方のエントリーのすべての組み合わせに対応する。結合フィールドは、出力結合テーブルに一度現れるだけである。例えば、図２Ａと２Ｂに示される２つのテーブルを結合するとその結果、図２Ｃに示される出力テーブルが与えられる。
【００１０】
しかし、もしも属性値の初期マッピングがそれぞれのディメンションで選択されて、そのディメンションのキー値の上にマッピングされる場合、ディメンションテーブルをファクトテーブルとクエリにおいて結合する必要はなく、なぜなら全ての必要な情報はファクトテーブルにあるからである。例えば、クエリは次のように示される。
【００１１】
【表２】
データベースがクエリを扱う方法に依存しているので、これはしばしば等価属性論理クエリよりもはるかに能率的であり、その理由はディメンションテーブルがクエリの中に含まれる必要がないからである。さらにデータベースエンジンは、多様な最適化による属性よりもはるかに能率的にキー値を処理可能である。
【００１３】
データベースは、ファクトテーブルを例えばそれぞれのディメンションのキー値によってインデックス付けることによって最適化可能である。適切なファクトデータは、結果として生じるデータセットを含んで、インデックスのそれぞれのキーに対するエントリーを通してスキャンする事によって非常に早く発見可能であり、その理由は特定のキーに関連するインデックスは、連続的に配列されるからである。
【００１４】
もしそのようなインデックスに基礎をおいた構成がデータベースに使用されるなら、以下の種類のクエリはしばしば、キー値上のクエリ処理の時でさえ、より有利である。
【００１５】
【表３】
現行のデータベースクエリ処理ツールによって用いられるどんなクエリ論理であるかに関わらず、それらは同じリクエストから適切なＳＱＬクエリへの変換を用い、そして、選択されたクエリ論理の使用をサーチされるエントリー数に無関係である。例えば、ある状況においては、特にディメンションにおいてより高いレベルであるとき、選択することによって選択基準に適合するディメンションテーブルからの多数のレコードを、結果としてもたらす。例えば、市場におけるすべてのミューチュアルファンドの全ての在庫資金が求められるかもしれない。実際、選択基準に一致している何百ものディメンションエントリがあるかもしれない。もしも、データベースクエリ処理ツールが自動的に設定されて、選択ディメンション属性エントリーがファンドディメンションのキー値に変換されるならば、そのディメンションは選択基準に一致するキー値を見つけようとしてサーチするだろう。該当するエントリーは、「ＩＮ」リストを使うクエリに上記のように加えられる。キー値が非常に大きくなる場合は問題が起きる。多くのデータベースシステムは、単一の「ＩＮ」リストにおいて値のナンバの制限を課しており、クエリツールはそれゆえにクエリを多くのクエリに分散し、データベースにおいてサーチする。更に、ディメンションがインデックス付けされていなかったとしても、ファクトテーブルだけを用いてキー値の重要な数字をクエリ処理する事は、少ない属性値をクエリ処理してそして、ディメンションをクエリに導入するよりも、長い時間がかかる。例えば、データベースエンジンが属性値に関連するディメンションテーブルの中から見つけ出して、それが一致しているかを見る事は、キー値が一致しているかどうかを見ることと同じ位に迅速である。もしも、等価クエリにおいて、属性値のナンバよりもキー値がはるかに多く存在している場合、関連するディメンションにおける属性値を見つけ出す事は、それらの一つが一致するかどうか全てのキー値を見てチェックするよりも、殆ど確実に早い。
【００１７】
クエリツールは、クエリ処理された実際の属性に依存している選択可能なクエリ構造から選ぶ事が出来るように要求される。
本発明は１以上のディメンションからの属性を含むデータリクエストからクエリを生成する方法を提供し、属性に対応するキー値は確かめられ、クエリを実行する為に必要な属性及びキー値の個数に依存するクエリにおけるキー値ロジックあるいは属性ロジックのいずれを使用すべきかを決定する為に用いられる。
【００１８】
【発明の実施の形態】
本発明による実施例は図３から図４に関連して、述べられる。
図３に示されるように、クエリジェネレータ２０は、アプリケーションサーバ２上のオブジェクトとして提供されている。クエリジェネレータは、外部リクエストを受け入れて、そこからＳＱＬクエリを生成する。これらのＳＱＬクエリは、データベース６からリクエストされたデータを検索するデータベースエンジン４に送られる。戻ったデータはその後データベースエンジンからアプリケーションサーバへと送り返されて、リクエスタ（ｒｅｑｕｅｓｔｏｒ）に送り返されるか、処理されて他のところ、例えばディスプレイサーバ１０へと送られる。
【００１９】
アプリケーションサーバは又、検索されることになっているファクトデータに関するデータベースに蓄えられたディメンションのレプリカ１２を記憶する。１以上の属性を含むリクエストが、クエリジェネレータによって受容されるとき、クエリジェネレータはディメンションエントリーを通してサーチし、そして、要求された全てのキー値を識別する。これはデータベースサーバへのクエリを使用することにより可能であるが、しかし、ずっと能率が悪い。
【００２０】
クエリジェネレータ２０は、それから以下の論理を用いてクエリ生成の方法を決定し、このことは図４のフローチャートに表現されている。
各ディメンションに対して、キー値のナンバが特定の経験的に決定されたしきい値以下である場合、単にキー値をファクトテーブルの中の値と比較してクエリの結果を得るのがより効率的であるとみなされる。この出願人によって具現化された実施例のシステムにとって、このしきい値の理想的な値は３０であると分かった。この場合、生成されたクエリはディメンションを含まず、単にファクトデータ上に作成される（このディメンションに関しては「クエリなし」と呼ばれ、ディメンションがリクエストされていないからである。）例えば、以下のクエリが生成される。
【００２１】
【表４】
しかし、キーのナンバが特定の予め定められたしきい値を越える場合は、生成されたクエリは、ファクトテーブルのディメンションへのインデックスがあるかないかによって変化する。
上に示されたように、ディメンションがインデックスを付けられる場合には、そのディメンションからのキー値は、非常に迅速にそのキー値を取り入れているファクトテーブルの適切なエントリーの上へとマッピングされる。
【００２３】
ディメンションキーがインデックスを付けられる場合、比較がなされて実行されて、クエリの中に現れるキー値のナンバが、ある一定の予め定められた定数Ａの倍数された属性値のナンバを越えるかどうかを見て、又経験的に進行する。この出願人によって具現化された実施例のシステムにとって、このしきい値の理想的な値は３０であると分かっており、しかし、この値は上述の議論されたしきい値に関連していない事が注目されるべきである。
【００２４】
キー値のナンバがこの値を越える場合、属性論理はより効果的となり、そして、属性クエリは生成される。例えば、「結合を有する」クエリは、以下の項を含んで生成される。「結合を有する」という言葉は、図２Ａ−２Ｃに関連して議論されたように、該当するディメンションテーブルとファクトテーブルとの間に結合を実行する事実に関している。クエリに基礎を置く全ての属性は、そのディメンションに関して「結合を有する」クエリであるという事が注目されるべきであり、何故ならば、ディメンションテーブルに対するリソースなしでは、属性値は確認される事が出来ないからである。
【００２５】
【表５】
しかし、キー値のナンバが属性値の定数Ａ倍をかけられたナンバを越えない場合は、「結合を有する」クエリに基礎をおいたキー値は、クエリにディメンションを含んで生成され、データベースエンジンの最適化されたインデックス処理を用いる。クエリは以下の項を含む。
【００２７】
【表６】
該当するディメンションがインデックスが付けられない場合は、例えあったとしても、キー値を使用する利点がより少ない。例えば、データベースエンジンが関連するディメンションテーブルの属性値を探し出してそれが一致するかをチェックする速さはそれが、キー値が一致するかどうかを見るくらいに速い。それゆえ、この場合においては、経験的な係数を確立する長さに向かうよりはむしろ、キー値のナンバと属性値ナンバとの単純な比較がなされる。しかし、この種の係数は適切であるなら、データベースエンジンに依存して使用され得る。
【００２９】
キー値の値がそのディメンションに対するクエリにおいて用いられる属性値のナンバよりも大きい場合は、「結合を有する」属性クエリは、クエリの中のそのディメンションに対して用いられる。一方、「結合を持たない」クエリキーはそのディメンションに対して用いられ、サーチにおいてディメンションを含む利点が、それがインデックスを付けられていないが故に、存在しない。
【００３０】
この選択算法はあらゆるディメンションに対して繰り返され、クエリは適切に生成されてデータベースクエリエンジンに転送される。
勿論、各々のディメンションの異なったクエリの性質によって、異なった結合は各々のディメンションに生成される。あるディメンションはクエリの中に含まれ、他のものは、含まれない。さらに、いくつかのディメンションは、属性論理を含み、他のものは含まない。例えば、以下の完全クエリは生成されて第１ディメンション及び第３ディメンションをそのクエリに含み、第１のものはキー値論理を使用し、第２のものは属性値論理を使用する。
【００３１】
【表７】
特定のリクエストは、これまでに記載されている場合よりも、より複雑である。例えば、「複式保持」リクエストは、ユーザーが複数の分離された選択（「保持」）をディメンションから作るときに起きる。この場合生成されるクエリは、句（ｃｌａｕｓｅ）をこの状況に対してモデル化する際にＯＲ論理を用いる必要がある。例えば、ユーザーがディメンションｄｉｍ１から選択するときに、複式「保持」を選ぶ場合を仮定する。第１保持は、属性ａｔｔｒ１とａｔｔｒ２とを含み、一方、第２保持は属性ａｔｔｒ３とａｔｔｒ４とを含む。生成されたクエリは以下のようでなければならない。
【００３３】
【表８】
この実施例によれば、この種類のクエリに関して、属性に基礎を置いたクエリに参照される各属性は、上記の算法（アルゴリズム）によって属性として計数される。キー値を使用する等価クエリは、最初に説明したのと同じフォーマットであり、単純な「ＩＮ」リストを有して、そして、キー値のナンバを確立すべき複雑さをそれゆえに加えない。
【００３５】
ユーザが、「ベース」計算（すなわちシェアのような「ｓｔｈ」）を含む測定を選ぶときは、しかしより複雑なシナリオが発生する。これは一般的に、与えられたディメンションからの「舞台裏の」追加的選択を必要とする。キー論理は、ディメンションのためのキーリストの追加的なキー値によってこの状況を解決する。属性論理は、複式「保持」に関連する構文の一番上の追加的ＯＲを実行する必要がある。（上の実例からの複式「保持」の一番上において）ユーザーがディメンションｄｉｍ１の追加的な選択を必要とする「ベース」計算を選択すると仮定し、それを今、属性ａｔｔｒ５からとしよう。クエリは以下のように読み取れる。
【００３６】
【表９】
この種の状況は、「複式保持」シナリオに似た方法で、処理される。
スター結合オプションは、属性論理オプションと、インデックス付けされたディメンションに基づいたスター結合を使用するある種のディメンションと、そして、標準属性論理を用いるある種のディメンションと、に連動して用いられることが注意されるべきである。単純な属性論理の場合がディメンションｄｉｍ１に用いられると仮定すれば、クエリは以下のように見られる。
【００３８】
【表１０】
この実施例のシステムの場合、ユーザプロファイルはユーザに対して戻されるデータをサブセット可能にする。ユーザはユーザだけが見る特権を与えられているそれらの記録に対してのみアクセスを有する。ベースはそれを実現するためにフィルタリング機構を使用する。属性論理の観点から、ユーザプロファイルは、ユーザがアクセスすることができるデータのサブセットを判定するディメンション選択の組である。ディメンションｄｉｍ１の為のユーザプロファイルが、ユーザは与えられた値のリストに属性ａｔｔｒＫ値が存在するそれらのレコードに対してのみアクセスし得ているように規定すると仮定すると、その属性論理によって生成されるクエリは以下のように見られる。
【００４０】
【表１１】
述べられた属性値は本発明のこの実施例の算法では単一属性値として扱われる。
属性論理は分割されたファクトセットによって打撃を受けない。物理的パーティションの場合、それぞれのパーティションは集約（ａｇｇｒｅｇａｔｅ）テーブルを用いる事によって画定される。一般的に、クエリは記載されるロジックを使用するそれぞれのパーティションに対して発行される。
【００４２】
本発明の好適な実施例が例示され記載されているが、当業者においては、変更と修正は本発明のより広い面から逸脱する事なく、為され得る事が理解されるべきである。本発明の多様な特徴は、請求項に記載されている。
【図面の簡単な説明】
【図１】例として、３つの生成関連テーブル及び対応するファクトテーブルを示している。
【図２Ａ】例としてのテーブルを示す。
【図２Ｂ】例としてのテーブルを示す。
【図２Ｃ】図２Ａ及び２Ｂに示されている２つのテーブルの結合を示す。
【図３】本発明の第１実施例によるシステム構成要素を示す。
【図４】本発明の第１実施例に従う選択算法を表現しているフローチャートである。
【符号の説明】
２ アプリケーションサーバ
６ データベース
１０ ディスプレイサーバ
１２ ディメンション
２０ クエリジェネレータ
Claims (6)
- データベースからデータを得るために使用されるクエリを生成する方法であって、
前記データベースはファクトテーブル及び１以上のディメンションテーブルを含み、各ディメンションテーブルはディメンションを表現しているデータを提供して前記データは一組のエンティティに対する一組の属性の中の属性値を含んで各エンティティはキー値によって識別され、前記ファクトテーブルはデータエントリを含んで各データエントリは前記各々のディメンションからのエンティティと関連づけられ、前記クエリは１以上の前記ディメンションからの１以上の前記属性値を指定するデータへのリクエストに基づいており、
各々のディメンションに対してその方法が、
前記ディメンションの前記属性値と関連付けられた前記ディメンションの全ての前記キー値を確立する行程と、
前記ディメンションの前記キーの前記ナンバおよび前記属性値の前記ナンバの関数としてそのディメンションにおけるキー値又は属性値のどちらに対してクエリ処理するか選択する行程と、
もしも属性値クエリが選択される場合には属性値を使用しているそのディメンションに対応する前記クエリの前記一部分を生成する行程と、
もしもキー値クエリが選択される場合にはキー値を使用しているそのディメンションに対応する前記クエリの前記一部分を生成する行程と、を含むことを特徴とするクエリ生成方法。 - 請求項１記載の方法であって、キー値又は属性値のいづれかへのクエリ選択の前記行程が、前記キー値のナンバをしきい値と比較する行程と、そして、
前記キー値のナンバが予め定められた値以下の場合は、前記ファクトデータテーブル上のキー値クエリを使用しているそのディメンションに対応するクエリの一部分を実行する行程と、を含むことを特徴とする方法。 - 請求項２記載の方法であって、前記ディメンションの前記キー値ナンバが前記予め定められたしきい値より大きい場合において、前記ディメンションに対応する前記クエリの前記一部分の実行は
もしも、前記クエリを実行するに必要な、キー値の属性値に対する比率がある一定値よりも低い場合には、属性値を使用して実行され、そして、
もしも、前記比率が前記比率値よりも高い時はキー値を使用して、
実行されることを特徴とする方法。 - 請求項３記載の方法であって、前記比率の値が、前記ディメンションがインデックス付けされているかどうかに依存することを特徴とする方法。
- 請求項３記載の方法であって、前記クエリの前記一部分がキー値を使用して実行される場合において、
もしも前記ディメンションがインデックス付けされていない場合は前記クエリの前記一部分は前記ファクトデータテーブルだけを使用して実行され、そして、
もしも前記ディメンションがインデックス付けされている場合は前記クエリは、前記ファクトデータテーブルを前記対応するディメンションテーブルに結合させてそして前記結合されたディメンションテーブルの前記ディメンションキーに対してクエリ処理することによって、実行されることを特徴とする方法。 - データベースからデータを得るためのクエリを生成する装置であって、
前記データベースはファクトテーブル及び１以上のディメンションテーブルを含み、各ディメンションテーブルはディメンションを表現しているデータを提供して前記データは一組のエンティティに対する一組の属性の中の属性値を含んで各エンティティはキー値によって識別され、前記ファクトテーブルはデータエントリを含んで各データエントリは前記各々のディメンションからのエンティティと関連づけられ、前記クエリは１以上の前記ディメンションからの１以上の前記属性値を指定するデータへのリクエストに基づいており、その装置が、
前記ディメンションの前記属性値と関連付けられた各ディメンションの全ての前記キー値を確立する手段と、
前記ディメンションの前記キーの前記ナンバおよび前記属性値の前記ナンバとの関数としてそのディメンションにおけるキー値又は属性値のどちらに対してクエリ処理するか選択する手段と、
もしも、属性値クエリが選択される場合には属性値を使用しているそのディメンションに対応する前記クエリの前記一部分を生成する手段と、
もしも、キー値クエリが選択される場合にはキー値を使用しているそのディメンションに対応する前記クエリの前記一部分を生成する手段と、を含むことを特徴とするクエリ生成装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/185,042 US6192357B1 (en) | 1998-11-03 | 1998-11-03 | Method and apparatus for optimizing query generation by selectively utilizing attributes or key values |
| PCT/US1999/025939 WO2000028439A1 (en) | 1998-11-03 | 1999-11-03 | Method and apparatus for optimizing query generation by selectively utilizing attributes or key values |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004520633A true JP2004520633A (ja) | 2004-07-08 |
Family
ID=22679320
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000581554A Pending JP2004520633A (ja) | 1998-11-03 | 1999-11-03 | 属性又はキー値を選択的に利用することによりクエリ生成を最適化する方法と装置 |
Country Status (12)
| Country | Link |
|---|---|
| US (1) | US6192357B1 (ja) |
| EP (1) | EP1049997B1 (ja) |
| JP (1) | JP2004520633A (ja) |
| CN (1) | CN1292125A (ja) |
| AT (1) | ATE358297T1 (ja) |
| AU (1) | AU755859B2 (ja) |
| BR (1) | BR9906714A (ja) |
| CA (1) | CA2325863A1 (ja) |
| DE (1) | DE69935657T2 (ja) |
| IL (1) | IL137127A (ja) |
| WO (1) | WO2000028439A1 (ja) |
| ZA (1) | ZA200003317B (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7130853B2 (en) * | 2000-06-06 | 2006-10-31 | Fair Isaac Corporation | Datamart including routines for extraction, accessing, analyzing, transformation of data into standardized format modeled on star schema |
| US6785666B1 (en) * | 2000-07-11 | 2004-08-31 | Revenue Science, Inc. | Method and system for parsing navigation information |
| US20030095145A1 (en) * | 2001-10-30 | 2003-05-22 | Jonathan Patrizio | System and method for table row selection in a GUI display |
| US20040133583A1 (en) * | 2002-11-20 | 2004-07-08 | Tingey Kenneth B. | system architecture and method for entering and accessing entity data in events accounting |
| US7103591B2 (en) * | 2002-12-02 | 2006-09-05 | International Business Machines Corporation | Method of describing business and technology information for utilization |
| US7627587B2 (en) * | 2003-09-25 | 2009-12-01 | Unisys Corporation | System and method for improving information retrieval from a database |
| KR100619016B1 (ko) * | 2004-05-06 | 2006-08-31 | 삼성전자주식회사 | 광 기록 정보 저장 매체, 기록/재생 장치 및 호스트 장치 |
| US7840607B2 (en) * | 2004-08-06 | 2010-11-23 | Siemens Aktiengesellschaft | Data mart generation and use in association with an operations intelligence platform |
| US7580922B2 (en) * | 2005-01-04 | 2009-08-25 | International Business Machines Corporation | Methods for relating data in healthcare databases |
| US7680781B1 (en) | 2005-03-04 | 2010-03-16 | Teradata Us, Inc. | Automatic search query generation and results set management |
| US7650196B2 (en) * | 2005-09-30 | 2010-01-19 | Rockwell Automation Technologies, Inc. | Production monitoring and control system having organizational structure-based presentation layer |
| US7590541B2 (en) * | 2005-09-30 | 2009-09-15 | Rockwell Automation Technologies, Inc. | HMI presentation layer configuration system |
| US7933900B2 (en) * | 2005-10-23 | 2011-04-26 | Google Inc. | Search over structured data |
| US7464083B2 (en) * | 2005-10-24 | 2008-12-09 | Wolfgang Otter | Combining multi-dimensional data sources using database operations |
| US20070185870A1 (en) | 2006-01-27 | 2007-08-09 | Hogue Andrew W | Data object visualization using graphs |
| US8954426B2 (en) * | 2006-02-17 | 2015-02-10 | Google Inc. | Query language |
| US8954412B1 (en) | 2006-09-28 | 2015-02-10 | Google Inc. | Corroborating facts in electronic documents |
| CN100498793C (zh) * | 2007-06-08 | 2009-06-10 | 北京神舟航天软件技术有限公司 | 用基于小波的压缩直方图实现二维谓词选择率估计的方法 |
| US7702622B2 (en) | 2007-06-29 | 2010-04-20 | Microsoft Corporation | Advanced techniques for SQL generation of performancepoint business rules |
| US8200604B2 (en) | 2007-06-29 | 2012-06-12 | Microsoft Corporation | Multi-platform business calculation rule language and execution environment |
| US8020144B2 (en) * | 2007-06-29 | 2011-09-13 | Microsoft Corporation | Metadata-based application deployment |
| CN102043866B (zh) * | 2011-01-25 | 2013-03-13 | 苏州普达新信息技术有限公司 | 基于表单特征的松弛搜索与优化排序方法 |
| US9785704B2 (en) * | 2012-01-04 | 2017-10-10 | Microsoft Technology Licensing, Llc | Extracting query dimensions from search results |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5440730A (en) * | 1990-08-09 | 1995-08-08 | Bell Communications Research, Inc. | Time index access structure for temporal databases having concurrent multiple versions |
| JPH077422B2 (ja) * | 1991-08-23 | 1995-01-30 | インターナショナル・ビジネス・マシーンズ・コーポレイション | コンピュータ処理データベース・システムにおけるジョインの実行方法及びシステム |
| JPH0756652B2 (ja) * | 1992-03-24 | 1995-06-14 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 動画像のフレーム列の検索 |
| US5359724A (en) * | 1992-03-30 | 1994-10-25 | Arbor Software Corporation | Method and apparatus for storing and retrieving multi-dimensional data in computer memory |
| US5572731A (en) * | 1992-12-30 | 1996-11-05 | Hewlett-Packard Company | Sequentially navigated object oriented computer system |
| JP3266351B2 (ja) * | 1993-01-20 | 2002-03-18 | 株式会社日立製作所 | データベース管理システムおよび問合せの処理方法 |
| US5713020A (en) * | 1993-09-02 | 1998-01-27 | Microsoft Corporation | Method and system for generating database queries containing multiple levels of aggregation |
| AU1522095A (en) * | 1994-01-05 | 1995-08-01 | Peter J. Covey | Dynamic-state, multi-dimensional, multi-media database |
| GB9417314D0 (en) * | 1994-08-27 | 1994-10-19 | Int Computers Ltd | Method for performing joins in a database system |
| US5675785A (en) * | 1994-10-04 | 1997-10-07 | Hewlett-Packard Company | Data warehouse which is accessed by a user using a schema of virtual tables |
| US5590324A (en) * | 1995-02-07 | 1996-12-31 | International Business Machines Corporation | Optimization of SQL queries using universal quantifiers, set intersection, and max/min aggregation in the presence of nullable columns |
| US5745754A (en) * | 1995-06-07 | 1998-04-28 | International Business Machines Corporation | Sub-agent for fulfilling requests of a web browser using an intelligent agent and providing a report |
| US5761652A (en) * | 1996-03-20 | 1998-06-02 | International Business Machines Corporation | Constructing balanced multidimensional range-based bitmap indices |
| US5832475A (en) * | 1996-03-29 | 1998-11-03 | International Business Machines Corporation | Database system and method employing data cube operator for group-by operations |
| US5974418A (en) * | 1996-10-16 | 1999-10-26 | Blinn; Arnold | Database schema independence |
| US5897622A (en) * | 1996-10-16 | 1999-04-27 | Microsoft Corporation | Electronic shopping and merchandising system |
| US5799300A (en) * | 1996-12-12 | 1998-08-25 | International Business Machines Corporations | Method and system for performing range-sum queries on a data cube |
| US5937408A (en) * | 1997-05-29 | 1999-08-10 | Oracle Corporation | Method, article of manufacture, and apparatus for generating a multi-dimensional record structure foundation |
-
1998
- 1998-11-03 US US09/185,042 patent/US6192357B1/en not_active Expired - Lifetime
-
1999
- 1999-11-03 AT AT99968035T patent/ATE358297T1/de not_active IP Right Cessation
- 1999-11-03 CN CN99803525A patent/CN1292125A/zh active Pending
- 1999-11-03 AU AU24731/00A patent/AU755859B2/en not_active Ceased
- 1999-11-03 JP JP2000581554A patent/JP2004520633A/ja active Pending
- 1999-11-03 EP EP99968035A patent/EP1049997B1/en not_active Expired - Lifetime
- 1999-11-03 CA CA002325863A patent/CA2325863A1/en not_active Abandoned
- 1999-11-03 DE DE69935657T patent/DE69935657T2/de not_active Expired - Lifetime
- 1999-11-03 BR BR9906714-5A patent/BR9906714A/pt not_active IP Right Cessation
- 1999-11-03 WO PCT/US1999/025939 patent/WO2000028439A1/en active IP Right Grant
- 1999-11-03 IL IL13712799A patent/IL137127A/xx not_active IP Right Cessation
-
2000
- 2000-06-30 ZA ZA200003317A patent/ZA200003317B/xx unknown
Also Published As
| Publication number | Publication date |
|---|---|
| EP1049997B1 (en) | 2007-03-28 |
| IL137127A (en) | 2005-06-19 |
| CN1292125A (zh) | 2001-04-18 |
| IL137127A0 (en) | 2001-07-24 |
| BR9906714A (pt) | 2000-10-17 |
| ZA200003317B (en) | 2002-12-02 |
| US6192357B1 (en) | 2001-02-20 |
| EP1049997A4 (en) | 2005-08-03 |
| EP1049997A1 (en) | 2000-11-08 |
| WO2000028439A1 (en) | 2000-05-18 |
| ATE358297T1 (de) | 2007-04-15 |
| DE69935657T2 (de) | 2007-12-13 |
| AU755859B2 (en) | 2003-01-02 |
| AU2473100A (en) | 2000-05-29 |
| DE69935657D1 (de) | 2007-05-10 |
| CA2325863A1 (en) | 2000-05-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004520633A (ja) | 属性又はキー値を選択的に利用することによりクエリ生成を最適化する方法と装置 | |
| Ilyas et al. | Rank-aware query optimization | |
| US11893022B2 (en) | Computer-implemented method for improving query execution in relational databases normalized at level 4 and above | |
| US6356892B1 (en) | Efficient implementation of lightweight directory access protocol (LDAP) search queries with structured query language (SQL) | |
| US7631012B2 (en) | System and method of operating a database | |
| US6405198B1 (en) | Complex data query support in a partitioned database system | |
| US7814042B2 (en) | Selecting candidate queries | |
| US6581055B1 (en) | Query optimization with switch predicates | |
| US10585867B2 (en) | Systems and methods for generating partial indexes in distributed databases | |
| US7409387B2 (en) | Materialized query table matching with query expansion | |
| US20080104070A1 (en) | Pattern-based filtering of query input | |
| Yang et al. | A framework for designing materialized views in data warehousing environment | |
| US20090119247A1 (en) | Efficient hash based full-outer join | |
| US20170357708A1 (en) | Apparatus and method for processing multi-dimensional queries in a shared nothing system through tree reduction | |
| EP2819030A1 (en) | Database hierarchy-independent data drilling | |
| CN113468208A (zh) | 生成数据查询语句的方法和装置、服务器及存储介质 | |
| JPH06314299A (ja) | データベース管理方法 | |
| US9378229B1 (en) | Index selection based on a compressed workload | |
| EP1384169B1 (en) | System and method of optimising queries in a database | |
| Konstantopoulos et al. | The Sevod Vocabulary for Dataset Descriptions for Federated Querying. | |
| JP3438699B2 (ja) | データベース管理方法およびシステム | |
| Kim et al. | SRT-rank: Ranking keyword query results in relational databases using the strongly related tree | |
| Liu et al. | Validation and performance evaluation of the partition and replicate algorithm | |
| Park et al. | Heuristic approach for early separated filter and refinement strategy in spatial query optimization | |
| Stoica Spahiu et al. | Fast Information Retrieval using Indexing Techniques |