JP2002007435A

JP2002007435A - 対話的分析データベースシステム及び対話的分析プログラムを記録した記録媒体

Info

Publication number: JP2002007435A
Application number: JP2000185484A
Authority: JP
Inventors: Takuya Kitano; 拓哉北野
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2000-06-20
Filing date: 2000-06-20
Publication date: 2002-01-11

Abstract

(57)【要約】【課題】時間や座標などの次元軸における連続した領域
での条件判定でタプルを集約する機能とその値をテーブ
ルで管理する機能を、対話型のＯＬＡＰサーバシステム
に装備する。【解決手段】標準ＳＱＬを拡張して、時間や座標などの
次元軸における連続した領域でのタプルのグループ化と
その集約値の計算を要求する記述を可能にし、前記拡張
したＳＱＬ文を入力するための対話型ユーザインタフェ
ースと、前記拡張したＳＱＬの構文を解釈する問合せ処
理手段と、前記ＳＱＬに含まれるユーザ定義のグループ
化と集約計算方法を実行するユーザ定義集約関数処理手
段と、前記ＳＱＬの構文解釈に従ってテーブルやそのデ
ータを管理するデータ管理手段と、前記テーブルやその
データを格納するデータベースとをＯＬＡＰサーバシス
テムに装備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、多次元データモデ
ル（データキューブモデル）に従う多次元データを管理
してユーザからの分析要求に応答するＯＬＡＰサーバシ
ステムに関するものであり、特に前記多次元データの集
合を集約して別の一つの多次元データとして管理可能な
ＯＬＡＰサーバシステム、前記多次元データをある属性
値での連続した領域での条件判定によって集約すること
が可能なＯＬＡＰサーバシステム、前記集約の定義や操
作をユーザが対話的に実行可能なＯＬＡＰサーバシステ
ムに関するものである。

【０００２】

【従来の技術】（ＯＬＡＰサーバシステムと多次元デー
タモデル）ＯＬＡＰサーバシステムの概要およびその技
術を説明した文献に以下の文献がある（文献［１］とす
る）。「ＳｕｒａｊｉｔＣｈａｕｄｈｕｒｉａｎｄ
ＵｍｅｓｈＤａｙａｌ、 "ＡｎＯｖｅｒｖｉｅｗ
ｏｆＤａｔａＷａｒｅｈｏｕｓｉｎｇａｎｄ
ＯＬＡＰＴｅｃｈｎｏｌｏｇｙ"、ＡＣＭＳＩＧＭ
ＯＤＲｅｃｏｒｄ、ｖｏｌ．２６、Ｎｏ．１、
ｐｐ．６５−７４、Ｍａｒｃｈ１９９７．」。以下
ではこの文献［１］を参考にしてＯＬＡＰサーバシステ
ムの概要およびその技術を説明する。

【０００３】ＯＬＡＰサーバシステムではデータの構造
をキューブに見なした多次元データモデル（データキュ
ーブモデル）に従ってデータを管理する。すなわち、キ
ューブを次元軸とその次元軸の各座標で特定される空間
とに分け、分析の対象となるデータを空間上に配置し、
その分析データを特徴づける属性データを次元軸上に配
置する。この分析対象のデータとその分析データを特徴
付ける属性データを組にしたデータを、本発明では多次
元データと呼ぶことにする。多次元データモデルに従っ
た多次元データの例を図２に示す。図２は文献［１］よ
り引用した多次元データを示す概念図である。図２の左
側の図がキューブであり、右側の図はキューブの次元軸
の階層構造を表している。図２のキューブは３次元のキ
ューブであり、次元（Ｄｉｍｅｎｓｉｏｎ；ディメン
ション）軸であるｘ軸にＤａｔｅ、ｙ軸にＰｒｏｄｕｃ
ｔ、ｚ軸にＣｉｔｙを置き、その各座標で特定されるキ
ューブの空間上に数量を表す数値を置いている。例えば
Ｄａｔｅが１で、ＰｒｏｄｕｃｔがＣｏｌａで、Ｃｉｔ
ｙがＮである数量は５０となる。

【０００４】また多次元データモデルでは、各次元に、
管理対象のデータを集約するための集約階層（ｈｉｅｒ
ａｒｃｈｉｃａｌｓｕｍｍａｒｉｚａｔｉｏｎｐａ
ｔｈ）を構成させることができる。図２の例では、Ｐｒ
ｏｄｕｃｔはＣａｔｅｇｏｒｙごとに集約し、Ｃａｔｅ
ｇｏｒｙはＩｎｄｕｓｔｒｙごとに集約する集約階層を
持つことを示している。またＣｉｔｙはＳｔａｔｅごと
に集約し、それをＣｏｕｎｔｒｙごとに集約する集約階
層があり、Ｄａｔｅは二種類の集約階層、一つはＤａｔ
ｅをＭｏｎｔｈに、そしてＱｕａｒｔｅｒ、Ｙｅａｒと
集約する階層構造と、もう一つはＤａｔｅをＷｅｅｋ
に、そしてＱｕａｒｔｅｒ、Ｙｅａｒと集約する集約階
層があることを示している。例えばＰｒｏｄｕｃｔで、
Ｊｕｉｃｅ、Ｃｏｌａ、ＭｉｌｋがＤｒｉｎｋｓという
Ｃａｔｅｇｏｒｙに属し、Ｃｒｅａｍ、Ｔｏｏｔｈｐａ
ｓｔｅ、ＳｏａｐがＣｏｓｍｅｔｉｃｓというＣａｔｅ
ｇｏｒｙに属しているとしたとき、Ｄａｔｅが１、Ｃｉ
ｔｙがＮ、そしてＰｒｏｄｕｃｔのＣａｔｅｇｏｒｙが
Ｄｒｉｎｋｓである数量の合計は８０となり、同様にＣ
ｏｓｍｅｔｉｃｓの合計数量は３７となる。

【０００５】（リレーショナルデータベースとスター・
スキーマ）このような多次元データモデルに従った多次
元データを管理するＯＬＡＰサーバの実装方法として、
リレーショナルデータベース（Ｒｅｌａｔｉｏｎａｌ
Ｄａｔａｂａｓｅ；ＲＤＢ）を利用するＲＯＬＡＰが
ある。

【０００６】ＲＯＬＡＰでは、ＲＤＢを用いて多次元デ
ータを複数のテーブル（ｒｅｌａｔｉｏｎ）に分けて管
理する。通常、一つのキューブに対して、各次元軸に対
応するそれぞれ一つのディメンション・テーブルを用意
し、空間データに対応する一つのファクト・テーブルを
用意する。各ディメンション・テーブルとファクト・テ
ーブルとの関係は１対多の関係となり、ファクト・テー
ブル側にディメンション・テーブルの主キーを参照する
外部キーを持たせる。このように一つのファクト・テー
ブルと複数のディメンション・テーブルで構成されるデ
ータベースのスキーマをスター・スキーマ（ｓｔａｒ
ｓｃｈｅｍａ）と呼ぶ。

【０００７】図２の多次元データをスター・スキーマで
表した例を図３に示す。ただし図３では次元としてＰｒ
ｏｄｕｃｔ、Ｄａｔｅ、Ｃｉｔｙの他に、Ｏｒｄｅｒ、
Ｃｕｓｔｏｍｅｒ、Ｓａｌｅｓｐｅｒｓｏｎを加えて６
次元で構成されている。次元の集約階層は各ディメンシ
ョン・テーブルの属性としてフラットに表されている。
集約階層に従った集約データを求めるには、ファクト・
テーブルとディメンション・テーブルを結合し、ディメ
ンション・テーブルの集約階層を表す属性で同じ値を持
つファクト・テーブルのタプル同士を集約することで実
現する。

【０００８】図３で集約階層がフラットの属性として表
現されていたディメンション・テーブルを、複数のテー
ブルに分割して管理する方法もある。このように、次元
の集約階層に基づいてディメンション・テーブルを複数
用意するスキーマをスノーフレーク・スキーマ（ｓｎｏ
ｗｆｌａｋｅｓｃｈｅｍａ）と呼ぶ。本発明ではスノ
ーフレーク・スキーマも広義のスター・スキーマと見な
して扱うことにする。

【０００９】ＲＯＬＡＰでは、前述のＰｒｏｄｕｃｔの
Ｃａｔｅｇｏｒｙごとの合計数量（Ｑｕａｎｔｉｔｙ）
を求めるためには、ファクト・テーブルとそれに関係す
る必要な数のディメンジョン・テーブルとを結合し（こ
れをスター・ジョインと呼ぶ）、結合したタプルの集合
に対して同じＣａｔｅｇｏｒｙの値を持つもの同士でグ
ループ化する。その各グループに対して集約関数ＳＵＭ
（Ｑｕａｎｔｉｔｙ）を適用して目的の合計数量を得
る。

【００１０】（マテリアライズド・ビュー）このような
ディメンジョン・テーブルの集約階層に従ってファクト
・テーブルのタプルをグループ化しその集約値を得る方
法には、分析要求時に計算する方法と、分析要求前にあ
らかじめ計算してマテリアライズド・ビュー（ｍａｔｅ
ｒｉａｌｉｚｅｄｖｉｅｗ）として用意する方法があ
る。典型的な分析要求が頻繁に発生したり、他の分析要
求に集計結果などのデータを効率良く再利用できるよう
なビューが存在する場合は、ＲＯＬＡＰにおける分析処
理の性能向上の観点からそれをマテリアライズド・ビュ
ーとして事前に用意するのが効果的である。

【００１１】（ビットマップ・インデックスとビットマ
ップ・ジョイン・インデックス）分析要求時に計算する
方法では、スター・ジョインを高速に実行するための仕
組みとして、ディメンション・テーブルとファクト・テ
ーブルとの関係に対してビットマップ・ジョイン・イン
デックスを、そしてディメンション・テーブルにおける
階層構造を表す属性に対してビットマップ・インデック
スをそれぞれ用意する方法がある。ビットマップ・ジョ
イン・インデックスは、ディメンション・テーブルとフ
ァクト・テーブルをあらかじめジョインした結果の関係
を、２次元のビットマップで表現したインデックスであ
る。すなわち、一方の次元にディメンション・テーブル
のタプルのＲＩＤ（ｒｏｗｉｄｅｎｔｉｆｉｅｒ；リ
レーショナルデータベースにおいて、テーブルで管理さ
れる各タプルを一意に特定する）又はＯＩＤ（ｏｂｊｅ
ｃｔｉｄｅｎｔｉｆｉｅｒ；オブジェクトリレーシ
ョナルデータベース又はオブジェクト指向データベース
において、テーブル又はクラスで管理される各タプル又
はオブジェクトを一意に特定する）を配置し、もう一方
の次元にファクト・テーブルのタプルのＲＩＤ又はＯＩ
Ｄを配置する（ＲＩＤもＯＩＤも共に一つのタプル又は
オブジェクトを一意に特定するＩＤなので、本発明では
以後、ＲＩＤとＯＩＤをまとめてＲＩＤと呼ぶことにす
る）。その各次元のタプルの組がジョイン後に関係があ
る場合はビット１を記録し、関係がない場合はビット０
を記録する。

【００１２】また、ビットマップ・インデックスは、２
次元のビットマップで、一方の次元にそのディメンショ
ン・テーブルのタプルのＲＩＤを配置し、もう一方の次
元にディメンション・テーブルのある属性の取り得る値
のリスト（すなわちその属性のドメイン）を配置する。
その後、各タプルごとに、その該当する属性値の場所に
ビット１を記録する。また、その他の該当しない属性値
の場所はすべてビット０を記録する。

【００１３】以上のビットマップ・ジョイン・インデッ
クスと、ビットマップ・インデックスにより、スター・
ジョインを高速に行うことが可能となり、またディメン
ション・テーブルの階層構造の属性で同じ値を持つスタ
ー・ジョイン後のタプル同士のグループ化を高速に行う
ことが可能となる。またこのグループ化と集約関数によ
って集約値を計算する操作をロールアップ（ｒｏｌｌｕ
ｐ）とよぶ。ロールアップの逆の操作で、ディメンショ
ン・テーブルの集約階層に従って集約値を計算したタプ
ルのグループを展開し、元のグループ化前の値を求める
操作をドリル・ダウン（ｄｒｉｌｌ−ｄｏｗｎ）とよ
ぶ。ドリル・ダウンの操作においても、ビットマップ・
インデックスとビットマップ・ジョイン・インデックス
を有効に利用して高速に実行することができる。

【００１４】（ＲＯＬＡＰにおける標準ＳＱＬと拡張Ｓ
ＱＬ）ＲＯＬＡＰでファクト・テーブルの集約値を求め
るには、前記マテリアライズド・ビューとしてあらかじ
め用意する場合でも、前記ビットマップ・ジョイン・イ
ンデックスと、ビットマップ・インデックスを用いて分
析要求時に計算する場合でも、タプルをグループ化する
操作が必須となる。このようなグループ化は、通常、Ｒ
ＤＢに対する問合せ言語ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ
ＱｕｅｒｙＬａｎｇｕａｇｅ）によってその内容と
方法が記述され、処理される。ＩＳＯ／ＩＥＣ９０７
５の標準ＳＱＬでは、ＧＲＯＵＰＢＹ句でリストした
属性で同じ値を持つタプル同士をグループ化する方法を
提供している。さらにＨＡＶＩＮＧ句で指定した条件が
Ｔｒｕｅとなるグループのみを結果として残すことも可
能である。しかし、ＧＲＯＵＰＢＹ句によってグルー
プ化したタプルの集合に対してさらにその集合の範囲を
限定するような条件を設定することはできない。この同
じ属性値を持つタプル同士をグループ化したタプルの集
合をさらに限定する方法として、以下の２つの文献では
標準ＳＱＬを拡張する方法が提案されている（順番に文
献［２］、文献［３］とする）。「Ｄａｍｉａｎｏｓ
ＣｈａｔｚｉａｎｔｏｎｉｏｕａｎｄＫｅｎｎｅｔ
ｈＡ．Ｒｏｓｓ、 "ＱｕｅｒｙｉｎｇＭｕｌｔ
ｉｐｌｅＦｅａｔｕｒｅｓｏｆＧｒｏｕｐｓｉｎ
ＲｅｌａｔｉｏｎａｌＤａｔａｂａｓｅｓ"、ｉｎ
Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ２２ｎｄ
ＩｎｔｅｒｎａｔｉｏｎａｌＣｏｎｆｅｒｅｎｃｅ
ｏｎＶｅｒｙＬａｒｇｅＤａｔａｂａｓｅｓ（Ｖ
ＬＤＢ）、ｐｐ．２９５−３０６、Ｓｅｐｔ．１
９９６．」、「ＫｅｎｎｅｔｈＡ．Ｒｏｓｓ、Ｄ
ｉｖｅｓｈＳｒｉｖａｓｔａｖａ、Ｄａｍｉａｎｏ
ｓＣｈａｔｚｉａｎｔｏｎｉｏｕ、 "Ｃｏｍｐｌｅ
ｘＡｇｇｒｅｇａｔｉｏｎａｔＭｕｌｔｉｐｌｅ
Ｇｒａｎｕｌａｒｉｔｉｅｓ"、ｉｎＰｒｏｃｅｅ
ｄｉｎｇｓｏｆｔｈｅ６ｔｈＩｎｔｅｒｎａｔ
ｉｏｎａｌＣｏｎｆｅｒｅｎｃｅｏｎＥｘｔｅｎ
ｄｉｎｇＤａｔａｂａｓｅＴｅｃｈｎｏｌｏｇｙ
（ＥＤＢＴ）、ｐｐ．２６３−２７７、Ｍａｒｃｈ
１９９８．」文献［２］、文献［３］で提案されてい
る図４の拡張ＳＱＬの構文について説明する。ＦＲＯＭ
句のＴ_１、．．．、Ｔ_ｐの各Ｔはテーブルであり、ＳＥ
ＬＥＣＴ句およびＧＲＯＵＰＢＹ句のＢ_１、．．．、
Ｂ_ｋ、Ａ_１、．．．、Ａ_ｎの各Ｂ、ＡはＴの属性であ
る。ＳＥＬＥＣＴ句のｆ_１、．．．、ｆ_ｎの各ｆはグル
ープ化したタプルの集合に対する集約関数である。ＷＨ
ＥＲＥ句のＣｏｎｄはテーブルＴに対するタプルの選択
条件であり、タプルのグループ化に先立って評価され
る。βは｛Ｂ_１、．．．、Ｂ_ｋ｝の任意の部分集合を表
し、このβの属性の組で同じ値を持つタプル同士をグル
ープ化する。この拡張ＳＱＬの構文では、このタプルの
グループ化に関して条件を与えることができる。まずＧ
ＲＯＵＰＢＹ句でグループ化変数（ｇｒｏｕｐｉｎｇ
ｖａｒｉａｂｌｅ）と呼ばれるＲ_１、．．．、Ｒ_ｍを
宣言する。このグループ化変数Ｒはグループ化するタプ
ルの集合を表し、ＳＬＥＣＴ句、ＳＵＣＨＴＨＡＴ
句、ＨＡＶＩＮＧ句でそれぞれ利用する。ＳＵＣＨＴ
ＨＡＴ句ではこのｍ個のＲで代表されるタプルの各集合
に対してｍ個の条件式Ｓ_１、．．．、Ｓ_ｍを与え、その
グループ化の条件とする。条件式Ｓのシンタックスは
Ｒ．とし、最初に対象とするタプルの集合を表すグルー
プ化変数Ｒを記述し、ドットを一つ記述してからグルー
プ化のためのを記述する。この条件式Ｓのセマンティク
スは、ドットの後に続く条件でＴｒｕｅとなるタプルを
Ｒのタプルの集合要素とする。例えば、Ｒ．Ｄａｔｅ
＜ "９６／０９／０１" ならばタプルの属性Ｄａｔｅ
の値が"９６／０９／０１"以下であることがＲに対する
タプルのグループ化条件となる。

【００１５】ＨＡＶＩＮＧ句には２つのセマンティクス
がある。一つは標準ＳＱＬのそれと同じであり、グルー
プ化したタプルの集合そのものに対する選択条件を記述
し、Ｔｒｕｅであるグループのみを結果として残す。例
えばｓｕｍ（Ｒ．Ｌｅｎｇｔｈ）＞＝ｓｕｍ（Ｌｅ
ｎｇｔｈ）／３ならば、Ｒのタプルの属性Ｌｅｎｇｔｈ
の合計値が、Ｒによらない全タプルのＬｅｎｇｔｈの合
計の１／３以上であるＲのグループのみが結果として返
却される。もう一つのセマンティクスはＳＵＣＨＴＨ
ＡＴ句のセマンティクスと同じであり、グループ化変数
Ｒを用いてさらにグループ化に関する条件を指定する。
例えばＲ．Ｌｅｎｇｔｈ＝ｍａｘ（Ｒ．Ｌｅｎｇｔ
ｈ）ならば、Ｒのタプルの構成要素は、そのＲの中でＬ
ｅｎｇｔｈの最大値を持つタプルのみとなる。ＳＥＬＥ
ＣＴ句では、標準ＳＱＬと同じく検索結果として取り出
すタプルの属性を記述する。図４の各ＡやＢにおいてグ
ループ化変数を用いて属性を記述することも可能であ
る。また、標準ＳＱＬではエラーとなるが、ＳＥＬＥＣ
Ｔ句のＢでＧＲＯＵＰＢＹ句のβに含まれない属性が
存在しても可としている。この場合、そのＢの属性には
特別な定数値ＡＬＬが返却される。

【００１６】（対話型ＳＱＬと手続き型ＳＱＬ）標準Ｓ
ＱＬも拡張ＳＱＬも共にＤＭＬ（ＤａｔａＭａｎｉｐ
ｕｌａｔｉｏｎＬａｎｇｕａｇｅ）として利用する場
合、その利用方法によっていくつかに分類される。その
一つの分類として、対話型（非カーソル型）ＳＱＬと手
続き型（カーソル型）ＳＱＬとに分けられる。対話型Ｓ
ＱＬは、タプルの集合に対して宣言的な操作を行う。す
なわち、タプルの一つずつに対する操作を記述せず、条
件を満たすタプルの集合に対して一括した操作を行う
（例外は、ＩＮＳＥＲＴ文におけるタプルの一行挿
入）。このような対話型ＳＱＬはコマンドライン・イン
タフェースを通してほぼすべてのデータ操作を実行させ
ることができる。一方手続き型ＳＱＬは、対話型ＳＱＬ
にカーソルという概念を用いて、タプルの集合から一つ
ずつデータを取り出して操作を行う。一般に手続き型Ｓ
ＱＬは第３世代（３ＧＬ）のプログラミング言語をホス
ト言語とし、そのホスト言語に埋め込むことによって利
用される。具体的には、ホスト言語で宣言するホスト変
数にカーソルで取り出したタプルを一つずつ渡し、それ
をホスト言語が持つ繰り返し、分岐、ジャンプなどの制
御構造を用いて文字通り手続き的に操作を記述する。こ
のように手続き型ＳＱＬでは複雑な分析処理を記述・実
行させることができるが、ホスト言語のコンパイル、実
行が必要なため、コマンドライン・インタフェースを通
した分析処理には不向きである。

【００１７】

【発明が解決しようとする課題】しかしながら、従来の
対話分析的データベースシステム及び対話的分析プログ
ラムを記録した記録媒体においては次のような問題があ
った。即ち、従来の技術で説明した標準ＳＱＬや文献
［２］、文献［３］で提案される従来の拡張ＳＱＬを対
話型ＳＱＬとして利用する場合、タプルの順序関係に基
づいたグループ化を行うことは不可能である。なぜな
ら、対話型ＳＱＬはタプルの集合に対して一括した操作
を宣言的に記述する手段しかなく、タプルの一つずつに
対する操作を記述することができないからである。「順
序付き属性の次元軸における連続した領域での条件判定
によってタプルをグループ化する手段」に関して図２６
と図５の例を用いて説明する。図２６は、ドメインがＤ
ｏｍ_Ｘ＝｛０、１、２、３、４｝、Ｄｏｍ_Ｙ＝
｛０、１、２、３、４｝、Ｄｏｍ_{ｃｏｌｏｒ}＝
｛ｗｈｉｔｅ、ｇｒａｙ｝、Ｄｏｍ_{ｖａｌｕｅ}＝Ｉｎ
ｔｅｇｅｒである４つの属性、Ｘ、Ｙ、ｃｏｌｏｒ、ｖ
ａｌｕｅからなるテーブルｍｅｓｈを表し、その２５個
のタプルの集合を示している。図５は図２６の属性Ｘ、
Ｙをそれぞれ次元軸として二次元上にタプルをマッピン
グした図である。ここで属性ｃｏｌｏｒの値がｇｒａｙ
であることを条件としてタプルをグループ化することを
考える。従来のＳＱＬで「ＳＥＬＥＣＴｃｏｌｏｒ、
ｓｕｍ（ｖａｌｕｅ）ＦＲＯＭｍｅｓｈＷＨＥ
ＲＥｃｏｌｏｒ＝ ’ｇｒａｙ’ ＧＲＯＵＰＢ
Ｙｃｏｌｏｒ；」と指定してグループ化すると、図２
６及び図５に示した８つのタプルが一つのグループとし
て括られる。このグループ化では、属性Ｘ、Ｙ上でのタ
プルの順序関係については何も考慮されない。しかし例
えば属性Ｘの値を時刻の時、属性Ｙの値を時刻の分とし
た時系列データでは、図２６に示した４つのグループの
ように、その時系列上で連続してｃｏｌｏｒがｇｒａｙ
となることを条件としてグループ化する多次元分析要求
も考えられる。また属性Ｘを経度、属性Ｙを緯度とする
ような地理データでは、図５の点線で囲った２つのグル
ープのように、二次元軸Ｘ、Ｙ上でタプルが連続してい
ることを条件としてグループ化する多次元分析要求も考
えられる。

【００１８】このようなグループ化を行うためには、従
来の手法では手続き型ＳＱＬのカーソルを用いてタプル
を一つずつ取り出し、ホスト言語を用いて論理的に条件
判断するプログラムを作成してコンパイルし実行してい
た。

【００１９】以下で、各用語の説明を行う。順序付き属
性とは、次の条件を満たす属性である。あるテーブルＴ
のタプルｔ_ｉ∈Ｔについて、Ｔの属性Ａによる≦Ａで全
順序関係が成り立ち、かつそのｔ_ｉの全順序関係が分析
上意味のある順序であるとき、この属性ＡをＴの順序付
き属性と呼ぶ。全順序関係が分析上意味を持つとは、例
えば時間を表す属性の値に基づいたデータの全順序関係
は、そのデータの経過や履歴を分析する目的では意味を
持つ。逆に分析上意味を持たない全順序関係では、患者
番号など患者の管理の都合で唯一に割り振られたＩＤ番
号などが挙げられる。患者を患者番号で全順序付けして
も患者の症例分析などには本質的には役に立たない。次
に、順序付き属性の次元軸について説明する。順序付き
属性の次元軸とは、順序付き属性の値に基づきタプルを
全射（ｏｎｔｏｍａｐｐｉｎｇ）して全順序付けする
ための分析軸のことである。図２６、図５の例でも示さ
れた通り、順序付き属性Ｘ、Ｙの値に従ってタプルを時
間軸（一次元軸）上に全射して順序付けする場合や、座
標軸（二次元軸）上に全射して順序付けする場合があ
る。

【００２０】このように、分析の対象とする次元軸によ
って、タプルの全順序関係が異なる。順序付き属性の次
元軸においてタプルが連続であることについて説明す
る。その前に、タプルの隣接について説明する。順序付
き属性Ａの値をある次元ＤＡの軸上に全射（ｏｎｔｏ
ｍａｐｐｉｎｇ）し、タプルｔ_ｉをそのＤＡ軸上で全順
序付けする。タプルｔ_１、ｔ_２∈Ｔが順序付き属性Ａの
次元ＤＡの軸上で隣接であるとは、ｔ_１＝Ａｔ_２の
場合。ｔ_１＜Ａｔ_２の場合、ｔ_１＜Ａｔ_ｉ＜Ａ
ｔ_２となるｔ_ｉ∈Ｔ（ｉ≠１、２）が存在しない。ｔ
_１＞Ａｔ_２の場合、ｔ_１＞Ａｔ_ｉ＞Ａｔ_２と
なるｔ_ｉ∈Ｔ（ｉ≠１、２）が存在しない。ことを満た
すことである。二つ以上の次元軸上でタプルが隣接する
とは、そのすべての順序付き属性の次元軸上で前記の隣
接に関する条件が成り立つことである。タプルの集合が
連続であるとは、その集合の中の任意の２組のタプルが
隣接しているか、または推移的に隣接していることであ
る。２つタプルが推移的に隣接しているとは、別の１つ
以上のタプルを介して隣接していることである。例えば
タプルｔ_１、ｔ_２∈Ｔが隣接し、タプルｔ_２、ｔ_３∈Ｔ
が隣接している場合、タプルｔ_１、ｔ_３はタプルｔ_２を
介して推移的に隣接しているという。二つ以上の次元軸
上でタプルが連続するとは、そのすべての順序付き属性
の次元軸上で前記の連続に関する条件が成り立つことで
ある。

【００２１】図５に示される灰色（ｇｒａｙ）の２つの
グループの例で、タプルの隣接について説明する。図５
の各タプルをｍｅｓｈ［Ｘ］［Ｙ］で表すことにする。
２つのグループとは、点線で囲った｛ｍｅｓｈ［０］
［１］、ｍｅｓｈ［１］［２］、ｍｅｓｈ［１］
［３］、ｍｅｓｈ［２］［３］、ｍｅｓｈ［２］
［４］｝と｛ｍｅｓｈ［３］［０］、ｍｅｓｈ［４］
［０］、ｍｅｓｈ［４］［１］｝の２つである。隣接に
関する一つの例として、ｍｅｓｈ［０］［１］とｍｅｓ
ｈ［１］［２］が隣接であることを示す。ｍｅｓｈ
［０］［１］＜Ｘｍｅｓｈ［１］［２］であるが、ｍ
ｅｓｈ［０］［１］＜Ｘｍｅｓｈ＜Ｘｍｅｓｈ
［１］［２］となるｇｒａｙのｍｅｓｈは存在しない。
よって、Ｘ軸上で隣接である。ｍｅｓｈ［０］［１］＜
Ｙｍｅｓｈ［１］［２］であるが、ｍｅｓｈ［０］
［１］＜Ｙｍｅｓｈ＜Ｙｍｅｓｈ［１］［２］とな
るｇｒａｙのｍｅｓｈは存在しない。よって、Ｙ軸上で
隣接である。よってｍｅｓｈ［０］［１］とｍｅｓｈ
［１］［２］は隣接である。また、ｍｅｓｈ［０］
［１］とｍｅｓｈ［１］［２］は同じ連続のグループに
属する。ｍｅｓｈ［２］［４］とｍｅｓｈ［３］［０］
が隣接でないことを示す。ｍｅｓｈ［２］［４］＜Ｘ
ｍｅｓｈ［３］［０］であるが、ｍｅｓｈ［２］［４］
＜Ｘｍｅｓｈ＜Ｘｍｅｓｈ［３］［０］となるｇｒ
ａｙのｍｅｓｈは存在しない。よって、Ｘ軸上では隣接
である。また、ｍｅｓｈ［２］［４］＞Ｙｍｅｓｈ
［３］［０］であり、ｍｅｓｈ［２］［４］＞Ｙｍｅ
ｓｈ＞Ｙｍｅｓｈ［３］［０］となるｇｒａｙのｍｅ
ｓｈが存在する。よって、Ｙ軸上では隣接しない。よっ
て（Ｘ、Ｙ）の二次元軸上ではｍｅｓｈ［２］［４］と
ｍｅｓｈ［３］［０］は隣接しない。またあるｇｒａｙ
のｍｅｓｈを介して推移的に隣接することもない。従っ
てｍｅｓｈ［２］［４］とｍｅｓｈ［３］［０］は同じ
連続のグループには属さない。

【００２２】従って、従来技術においては、当然なが
ら、上記連続条件により得られる従来の次元に対して一
括宣言的な集約階層に依らない新型の集約データに対す
る運用管理手段を持たない。以下では、この傍系の課題
について説明する。

【００２３】例えば、図２７に示すような、ある患者の
体温と血圧の値を日ごとに記録した「患者の体温−血圧
テーブル」があったとする。ここで次のような分析要求
を考える。「体温は３７．０℃以上、最高血圧は１４０
ｍｍＨｇ以上、最低血圧は９０ｍｍＨｇ以上であること
をそれぞれの記録において異常（図２７の灰色のデー
タ）であるとし、各記録において記録日の昇順で異常が
連続して続いた状態を異常状態と呼ぶことにする。体温
および（最高血圧、最低血圧）の組の異常状態ごとに、
その各属性値の平均値を求めよ。」図２７において、順
序付き属性を記録日とする。分析処理では、この記録日
の軸上で体温、最高血圧、最低血圧のそれぞれが異常状
態である期間中のタプルをグループ化し、その各グルー
プ（タプルの集合）における平均値を求めなければなら
ない。体温が３７．０℃以上の異常状態を高熱状態、最
高血圧が１４０ｍｍＨｇ以上かつ最低血圧が９０ｍｍＨ
ｇ以上の異常状態を高血圧状態と呼ぶことにする。図２
７において高熱状態は２つある。それぞれ期間が［１／
１３、１／１５］、［１／１９、１／２１］のとき
である。この各期間中における体温の平均値は、それぞ
れ３７．８ ℃、３７．５℃となる。一方、高血圧状態
は２つある。それぞれ期間が［１／１５、１／１
６］、［１／１９、１／１９］のときである。この各
期間中におけるそれぞれの平均値は、最高血圧が１４５
ｍｍＨｇ、１５２ｍｍＨｇ、最低血圧が９５ｍｍＨｇと
９１ｍｍＨｇとなる。この記録日におけるタプルの連続
を考慮した高熱状態、高血圧状態のグループ化とその各
値の平均値を計算した結果をテーブルとして表したのが
それぞれ図２８、図２９となる。これらは、図２７のテ
ーブルに対する集約テーブル（ビューテーブル、サマリ
ーテーブル）となる。

【００２４】従来技術は、このような集約テーブルを格
納するための手段、そしてこのグループ化と集約の逆の
操作であるドリル・ダウン操作、すなわち図２８、図２
９の集約テーブルから図２７の中の該当するタプルを特
定する手段を持たない。従来のＯＬＡＰサーバシステム
では、キューブの次元軸やスター・スキーマのディメン
ション・テーブルの集約階層に従い、その次元軸上で同
じ値を持つタプル同士を集約する計算がほとんどであ
る。標準ＳＱＬで説明すると、ＧＲＯＵＰＢＹ句で指
定した属性で同じ値を持つタプル同士をグループ化し、
それに対して集約計算を行う。事実、従来のＯＬＡＰサ
ーバシステムでは次元の集約階層に従った集約データを
マテリアライズド・ビューとしてあらかじめ用意した
り、同じ属性値を持つタプル同士を高速にグループ化す
るためにビットマップ・インデックスを用意したりする
などの技術が中心であった。

【００２５】しかし本発明の図２８や図２９の例で見ら
れるように、ある属性に関して同じ値を有するタプル同
士を集約する方法以外に、ある値の大小関係を条件にし
てタプルをグループ化したり、それがある順序付き属性
の次元軸に沿って連続してＴｒｕｅとなるタプル同士を
グループ化したりするなど、さまざまなグループ化の条
件を設定して集約テーブルを作成する要求が存在する。

【００２６】更に、その際の新型の集約データの運用管
理手段としては、これらの集約方法はスター・スキーマ
のディメンション・テーブルの集約階層に依存しないた
め、従来の技術で説明したスター・スキーマに従ったビ
ットマップ・ジョイン・インデックスやビットマップ・
インデックスを用いることができない。また、グループ
化したタプルからグループ化前のタプルに展開するドリ
ル・ダウンの操作でも、これらのインデックスを用いる
ことができない。

【００２７】従って、従来のビットマップ・インデック
スに代わる別の方法によって、集約後のテーブルから元
の集約前のタプルを特定する手段である必要がある。

【００２８】本発明は、以上の従来技術における問題に
鑑みてなされたものであり、対話性を保ちつつ新たな分
析手法を備えた対話分析的データベースシステム及びに
対話的分析プログラムを記録した記録媒体を提供するこ
とを目的とする。

【００２９】

【課題を解決するための手段】前記課題を解決するため
に提供する本願第一の発明に係る対話分析的データベー
スシステムは、対話型ユーザインタフェースと、このイ
ンターフェースで使用される対話型問合せ言語と、この
問合せ言語の構文を解釈する問合せ処理手段と、前記問
合せ言語の構文解釈に従ってデータを運用管理するデー
タ管理手段と、前記データを格納するデータベースとを
備え、データを対話的かつ多次元分析的に運用管理する
ＯＬＡＰサーバシステムである対話分析的データベース
システムにおいて、順序付け可能属性（ｏｒｄｉｎａｌ
ａｔｔｒｉｂｕｔｅ）を有する一以上の次元の順序に
よる多次元データの隣接概念に基づく多次元分析要求と
その結果を管理する分析結果管理要求とを記述する拡張
された対話型問合せ言語と、この拡張された対話型問合
せ言語の構文を解釈する拡張された問合せ処理手段と、
この構文解釈に従ってデータを運用管理するデータ管理
手段とを備えたことを特徴とする。

【００３０】順序付け可能属性（ｏｒｄｉｎａｌａｔ
ｔｒｉｂｕｔｅ）を有する一以上の次元の順序による多
次元データの隣接概念に基づく多次元分析要求とその結
果を管理する分析結果管理要求とを記述する拡張された
対話型問合せ言語と、この拡張された対話型問合せ言語
の構文を解釈する拡張された問合せ処理手段と、この構
文解釈に従ってデータを運用管理するデータ管理手段と
を備えたことにより、次元の順序付け可能属性に基づく
新たな分析手法を対話的に行える。

【００３１】前記課題を解決するために提供する本願第
二の発明に係る対話分析的データベースシステムは、本
願第一の発明に係る対話分析的データベースシステムに
おいて、前記データ管理手段が多次元データを表現する
各テーブルとそのスター・スキーマによりデータを運用
管理すると共に、前記拡張された対話型問合せ言語が対
話型の拡張ＳＱＬであることを特徴とする。

【００３２】前記データ管理手段が多次元データを表現
する各テーブルとそのスター・スキーマによりデータを
運用管理すると共に、前記拡張された対話型問合せ言語
が対話型の拡張ＳＱＬであることにより、従来のＲＯＬ
ＡＰ方式に基づいて、システムを構築できる。

【００３３】前記課題を解決するために提供する本願第
三の発明に係る対話分析的データベースシステムは、本
願第二の発明に係る対話分析的データベースシステムに
おいて、前記多次元分析要求が、標準ＳＱＬの条件判定
に加えて前記隣接概念による連続した領域であることを
条件に前記テーブルのタプルをグループ化し集約する連
続集約要求を含むことを特徴とする。

【００３４】隣接概念による連続した領域であることを
条件に前記テーブルのタプルをグループ化し集約する連
続集約要求を含むことにより、順序付き次元に関する連
続性を条件としてデータの集約が行える。

【００３５】前記課題を解決するために提供する本願第
四の発明に係る対話分析的データベースシステムは、本
願第三の発明に係る対話分析的データベースシステムに
おいて、前記多次元分析要求が、前記連続集約要求によ
り生成された集約データに対し、ユーザ定義集約関数に
よりその集約値を求める要求を含むことを特徴とする。

【００３６】連続集約要求により生成された集約データ
に対し、ユーザ定義集約関数によりその集約値を求める
要求を含むことにより、更に、柔軟で高度の分析が行え
る。

【００３７】前記課題を解決するために提供する本願第
五の発明に係る対話分析的データベースシステムは、本
願第四の発明に係る対話分析的データベースシステムに
おいて、前記拡張ＳＱＬが、グループ化属性、集約属
性、範囲属性、派生属性、ファクトグループ参照属性の
５種類の属性を選択的に有するテーブル定義を有し、前
記分析結果管理要求が、前記集約結果を前記拡張ＳＱＬ
で定義したテーブルとしてデータベースに格納し管理す
る要求を含むことを特徴とする。

【００３８】分析結果管理要求が、前記集約結果を前記
拡張ＳＱＬで定義したテーブルとしてデータベースに格
納し管理する要求を含むことにより、新型のデータを従
来のテーブルのスタースキーマによる管理方式と平行し
て行え、変更の必要性が低減する。また、テーブルをマ
テリアライズド・ビューとして用意すれば、各種操作を
迅速に行える。

【００３９】前記課題を解決するために提供する本願第
六の発明に係る対話的分析プログラムを記録した記録媒
体は、データを対話的かつ多次元分析的に運用管理する
ために対話型ＳＱＬ（ＳＱＬ非カーソル型）を解釈し実
行するプログラムを記録した対話的分析プログラムを記
録した記録媒体であって、対応する拡張ＳＱＬを解釈
し、順序付け可能属性（ｏｒｄｉｎａｌａｔｔｒｉｂ
ｕｔｅ）を有する一以上の次元の順序によるレコードの
隣接概念に基づいてデータを集約し新たなデータとして
運用管理可能にするプログラムを記録したことを特徴と
する。

【００４０】対応する対話型の拡張ＳＱＬを解釈し、順
序付け可能属性（ｏｒｄｉｎａｌａｔｔｒｉｂｕｔ
ｅ）を有する一以上の次元の順序によるレコードの隣接
概念に基づいてデータを集約し新たなデータとして運用
管理可能にするプログラムを記録したことにより、次元
の順序付け可能属性に基づく新たな分析手法並びにその
結果の運用管理を対話的に行える。

【００４１】

【発明の実施の形態】以下に、本発明に係る対話分析的
データベースシステム及び対話的分析プログラムを記録
した記録媒体の一実施の形態における構成について図面
を参照して説明する。図１は、本発明に係る対話分析的
データベースシステム及び対話的分析プログラムを記録
した記録媒体の一実施の形態における構成を示すブロッ
ク図、図６は、本発明に係る対話分析的データベースシ
ステム及び対話的分析プログラムを記録した記録媒体の
一実施の形態における多次元分析要求を入力するために
ユーザが記述する拡張ＳＱＬの構文を示す図、図７は、
本発明に係る対話分析的データベースシステム及び対話
的分析プログラムを記録した記録媒体の一実施の形態に
おける拡張ＳＱＬのＧＲＯＵＰＢＹ句、ＳＵＣＨＴ
ＨＡＴ句、ＨＡＶＩＮＧ句の構文を示す図、図８は、本
発明に係る対話分析的データベースシステム及び対話的
分析プログラムを記録した記録媒体の一実施の形態にお
けるファクトの集合を管理するファクトグループ参照属
性を有するステート・テーブルを示す図である。図２７
乃至図２９は、発明が解決しようとする課題でも用いた
例題データと本発明に係わるその集約データ表現である
テーブルである。本実施形態の対話分析的データベース
システムは、ＯＬＡＰ技術を利用したＯＬＡＰサーバシ
ステムであり、図１に示すように、拡張ＳＱＬが入力さ
れる対話型ユーザインタフェース１と、その構文を解釈
する問合せ処理手段２と、ユーザ定義集約関数処理手段
３と、データ管理手段４と、データベース５とによりな
る。そして、順序付き属性の次元軸においてタプルの集
合が連続して条件を満たすことをグループ化の条件とす
るかどうかを指定することができる問合せ言語として拡
張ＳＱＬを用意する。

【００４２】本実施のＯＬＡＰサーバシステムで扱う問
合せ言語は、図４の従来の拡張ＳＱＬのＧＲＯＵＰＢ
Ｙ句をさらに拡張した図６のＳＱＬとする。ＧＲＯＵ
ＰＢＹ句、ＳＵＣＨＴＨＡＴ句、ＨＡＶＩＮＧ句の構
文図も合わせて図７に示す。図７のｅｘｔｅｎｄｅ
ｄｃｌａｕｓｅの部分が本発明で拡張した構文であ
る。図７のｅｘｐｒおよびｃｏｎｄｉｔｉｏｎは、そ
れぞれ標準ＳＱＬにおける式および条件式のシンタック
スと同じとする。またｖａｌｕａｂｌｅは図４で説明し
たグループ化変数である。γは｛Ａ_１、．．．、Ａ_ｎ、
Ｂ_１、．．．、Ｂ_ｋ｝の中の順序付き属性で構成され
る任意の部分集合を表し、このγの属性の次元軸上で連
続して条件を満たすタプルをグループ化する。また、連
続の定義にはＶＥＣＴＯＲとＳＣＡＬＡＲの二種類があ
り、このいずれか一方を指定する。ＶＥＣＴＯＲの場合
は、γで指定したすべての属性に関して連続が成立する
タプルの集合でグループ化することを表し、ＳＣＡＬＡ
Ｒの場合は、γで指定した属性の順序で標準ＳＱＬのＯ
ＲＤＥＲＢＹを行った一次元軸上で連続が成立するタ
プルの集合でグループ化することを表す。ＧＲＯＵＰ
ＢＹ句でＯＮ句を用いなかった場合は、タプルの集合に
おいて連続して条件を満たすことを条件としたグループ
化は行われない。ＳＥＬＥＣＴ句のＣ_１、．．．、Ｃ_ｑ
は派生属性であり、テーブルＴの直接的な属性ではな
く、他の属性や外部の変数などから二次的に計算した値
を持つ属性である。

【００４３】また、新型データに対して、従来型データ
に対するのと同等以上の操作性を得るために、既存の集
約関数をビルト・イン関数式として標準ＳＱＬの文に記
述する手段の他に、第一の手段で説明した拡張ＳＱＬの
ＳＥＬＥＣＴ句、ＳＵＣＨＴＨＡＴ句、ＨＡＶＩＮＧ
句で、グループ化変数を用いたユーザ定義集約関数式を
記述できるようにセマンティクスを拡張する。グループ
化変数をＲ、ユーザ定義集約関数ｕｄｆ（）としたと
き、各句における式の記述方法はＲ．ｕｄｆ（）とな
る。ｕｄｆ（）は０以上のパラメータを指定することが
可能であり、その関数が評価する対象は、Ｒによって限
定されるタプルの集合とする。関数ｕｄｆ（）の評価前
と評価後のＲのタプルの集合は異なり、Ｒ．ｕｄｆ（）
の評価後の返却値はＴｒｕｅ、Ｆａｌｓｅ、Ｕｎｋｎｏ
ｗｎのいずれかとする。ＳＥＬＥＣＴ句でＲ．ｕｄ
ｆ（）が用いられた場合、ｕｄｆ（）によって限定され
たＲのタプルが返却の対象となる。返却するタプルの属
性値を限定する場合は、Ｒ．ｕｄｆ（）．ａｔｔ１とい
うように、属性ａｔｔ１を指定することを可とする。Ｓ
ＵＣＨＴＨＡＴ句でＲ．ｕｄｆ（）が用いられた場
合、Ｒ．ｕｄｆ（）を評価することによって限定された
タプルの集合がＲとなる。ＨＡＶＩＮＧ句でＲ．ｕｄｆ
（）が用いられた場合、Ｒ．ｕｄｆ（）を評価すること
によって限定されたタプルの集合をＲとし、かつその評
価結果がＴｒｕｅであるＲのみを結果として残す。そし
て、ユーザ定義関数は、図１に示す本実施のＯＬＡＰサ
ーバシステムのユーザ定義集約関数処理手段３において
実装される。前記ユーザ定義集約関数の式を含むＳＱＬ
は問合せ処理手段２によって解釈され、問合せ処理手段
２によって前記ユーザ定義関数が呼び出され、実行され
る。

【００４４】更に、新型データの管理手段として、まず
グループ化されたタプルの集合とそれに対する集約デー
タを一つのタプルとするテーブルを導入する。グループ
化されたタプルの集合とそれに対する集約データを一つ
のタプルとするテーブルの例は、図２７のテーブルに対
してある一定の条件でグループ化し、そのグループ化し
たタプルの集合とそれの集約データを一つのタプルに対
応付けた図２８、図２９のテーブルである。本実施形態
では、図２７のようにグループ化の対象となるテーブル
をファクト・テーブルと呼び、図２８、図２９のように
グループ化後の集約データを含むテーブルをステート・
テーブルと呼ぶことにする。またファクト・テーブルに
おけるタプルをファクトと呼び、ステート・テーブルに
おけるタプルをステートと呼ぶことにする。前記ファク
ト・テーブルは、従来の技術で説明したスター・スキー
マにおけるファクト・テーブルと同じ意味と構造を持つ
ものとする。ステート・テーブルは本実施のＯＬＡＰサ
ーバシステムが扱うスター・スキーマにおいて新しく導
入するテーブルである。ステートは以下の５種類のうち
いくつかの種類の属性を持つものとする。１）グループ化属性（同じ値を持つファクト同士でグル
ープ化するために指定される属性。ＳＱＬでいえば、Ｇ
ＲＯＵＰＢＹ句で指定される属性）、２）集約属性（グループ化したファクトの集合から求め
られる集約値を格納する属性）、３）範囲属性（集約属性の一種、グループ化したファク
トの集合に対する、順序付き属性の最大値または最小値
を格納する属性）、４）派生属性（上記の１）〜３）の属性、または外部の
変数などから二次的に計算した値を格納する属性）、５）ファクトグループ参照属性（グループ化したファク
トのＲＩＤの集合を管理する属性）。ステート・テーブルは、本発明のＣＲＥＡＴＥＳＴＡ
ＴＥ文を用いて定義する。ＣＲＥＡＴＥＳＴＡＴＥ文
は、標準ＳＱＬのＣＲＥＡＴＥＶＩＥＷ文の構文と以
下の点を除いて基本的に同じとする。１）ＣＲＥＡＴＥＶＩＥＷのＶＩＥＷという予約語
をＳＴＡＴＥに変更する２）ＣＲＥＡＴＥＳＴＡＴＥのＡＳ句以下の副問合
せ部で、本発明の拡張ＳＱＬ（図６、図７）を用いる。ステート・テーブルの属性は、ＣＲＥＡＴＥＳＴＡＴ
Ｅ文のＳＥＬＥＣＴ句で式として記述される属性であ
る。ただしファクトグループ参照属性については、本実
施形態ではＳＥＬＥＣＴ句で明示せず、ＦＲＯＭ句で指
定したファクト・テーブルと同名の属性として暗黙のう
ちに有することとする。またステート・テーブルは、標
準ＳＱＬによって生成されるビューと異なり、論理的な
仮想テーブルではなく物理的な実テーブルとして生成さ
れるマテリアライズド・ビューとする。よってステート
・テーブルのタプル、すなわちステートにはＲＩＤが付
加され、ＲＩＤによってステートを一意に特定すること
が可能である。グループ化したファクトの集合を管理す
るファクトグループ参照属性についてさらに詳しく説明
する。ステートとファクトの間には、グループ化による
１対多の関係がある。従来のスター・スキーマに基づく
ディメンションとファクトの１対多の関係は、ビットマ
ップ。インデックスとビットマップ・ジョイン・インデ
ックスによって保持される。

【００４５】しかし、ファクトのグループ化によってス
テートを作成する本実施の方法では、前記ビットマッ
プ．インデックスとビットマップ・ジョイン・インデッ
クスを利用しないので、これらインデックスによってそ
の１対多の関係を保持することはできない。そこで本実
施のステートの構造として、グループ化したファクトの
ＲＩＤの集合を管理するファクトグループ参照属性を用
意する。

【００４６】前記ステートの構造に関するイメージを図
８に示す。図８の右側にあるファクト・テーブルＦａｃ
ｔ１は通常の属性とＲＩＤで構成され、そのデータとし
て４つのタプルがあることを示している。ＲＩＤはユー
ザによって明確に用意される場合もあるし、ＤＢＭＳに
よって暗黙のうちに用意される場合もある。図８の左側
にあるステート・テーブルＳｔａｔｅ１は通常の属性
と、ファクトのＲＩＤの集合を管理するファクトグルー
プ参照属性とで構成され、そのデータとして２つのタプ
ルがあることを示している。ファクトグループ参照属性
の名前は、対象とするファクトのテーブル名と同名のＦ
ａｃｔ１である。この属性Ｆａｃｔ１の型（ｔｙｐｅ）
は、１９９９年版のＩＳＯ／ＩＥＣ９０７５：１９９
９の標準ＳＱＬの用語を用いて説明すれば、ファクト・
テーブルのタプルのＲＩＤを参照するＲｅｆｅｒｅｎｃ
ｅｔｙｐｅ（ＲＥＦ型）のデータのＣｏｌｌｅｃｔｉ
ｏｎｔｙｐｅ（コレクション型）となる。

【００４７】本実施の図１に示すＯＬＡＰサーバシステ
ムでは、ステート・テーブルのステートを実際に作成す
る際に、グループ化によって集めたファクトのＲＩＤを
データ管理手段４がファクトグループ参照属性の要素と
して一つずつ挿入していく。そしてそのステートがデー
タベース５に格納される。本実施形態のステートの構造
を有することにより、ステートを構成するファクトの集
合をＲＩＤによって直接的に求めることが可能となる。
本実施形態ではこの操作をドリル・ダウンと呼ぶことに
する。

【００４８】以上の拡張ＳＱＬによって順序付き属性の
次元軸における連続した領域での条件判定によってタプ
ルをグループ化する多次元分析要求を記述することが可
能となり、上記拡張ＳＱＬを用いたデータ定義、データ
操作の要求を対話型ＳＱＬとして入上記対話型ユーザイ
ンタフェース１に入力することとなる。そして、入力さ
れたＳＱＬ文は問合せ処理手段２によって解釈され、そ
の解釈を元にしてデータ管理手段４がデータベース５に
対してテーブルやデータを作成したり、検索したりす
る。以上の流れに関して、以下に５つの動作形態を説明
する。

【００４９】次に、本発明に係る対話分析的データベー
スシステム及び対話的分析プログラムを記録した記録媒
体の一実施の形態における動作について図面を参照して
以下に説明する。（動作形態１）ある次元軸において連続して条件を満た
すタプルの集合をグループ化する動作形態を、図９、図
１０、図１１、図１２に基づいて説明する。図９は、標
準ＳＱＬによる多次元分析要求の記述例を示す図、図１
０は、従来の拡張ＳＱＬによる多次元分析要求の記述例
を示す図、図１１は、図２および図３で示される多次元
データモデルに従う多次元データで、ＰｒｏｄＮｏ＝０
０１の１９９７〜１９９９年のＱｕａｎｔｉｔｙの値を
示すグラフの図、図１２は、本発明に係わる拡張ＳＱＬ
による多次元分析要求の記述例を示す図である。まず、
図３に示すスター・スキーマに従う多次元データにおい
て、次の多次元分析要求を実行する従来の対照例を示
す。「Ｆａｃｔｔａｂｌｅで管理されるＱｕａｎｔｉ
ｔｙに関して。各Ｐｒｏｄｕｃｔの各Ｙｅａｒごとに、
その年のＱｕａｎｔｉｔｙの平均値を上回っていたＱｕ
ａｎｔｉｔｙの平均値を求めよ」この分析要求を標準Ｓ
ＱＬで表現した例を図９に示す。また、図４で示した文
献［２］、文献［３］で提案されている従来の拡張ＳＱ
Ｌによって表現すると図１０のようになる。図３のスタ
ー・スキーマに従うデータの一部として、図１１に示す
ような「ＰｒｏｄＮｏが００１であるＰｒｏｄｕｃｔに
関して、１９９７年から１９９９年におけるＱｕａｎｔ
ｉｔｙの値」がデータベースに格納されているとする。
この図１１のデータに対して図９、図１０で示したＳ
ＱＬを適用すると、結果として１９９７年のＱｕａｎｔｉｔｙの平均値を上回っていた
ａ、ｂの領域上でのＱｕａｎｔｉｔｙの平均値１９９８年のＱｕａｎｔｉｔｙの平均値を上回っていた
ｃ、ｄの領域上でのＱｕａｎｔｉｔｙの平均値１９９９年のＱｕａｎｔｉｔｙの平均値を上回っていた
ｅ、ｆの領域上でのＱｕａｎｔｉｔｙの平均値の３つのデータが得られることになる。以上の多次元分
析要求を少し変更して、以下の多次元分析要求について
の適用を考える。「Ｆａｃｔｔａｂｌｅで管理される
Ｑｕａｎｔｉｔｙに関して、各Ｐｒｏｄｕｃｔの各Ｙｅ
ａｒごとに、その年のＱｕａｎｔｉｔｙの平均値を連続
して上回っていた期間ごとのＱｕａｎｔｉｔｙの平均値
を求めよ」発明が解決しようとする課題で述べたよう
に、従来の標準ＳＱＬまたは拡張ＳＱＬでは、この時間
軸上で連続して条件を満たすタプルの集合に対する集約
計算を対話型として実行することは不可能である。ただ
し、ＳＱＬのカーソルを用いて手続き的に処理を記述
し、それをホスト言語に埋め込みコンパイルして実行す
れば前記要求の実現は可能であり、従来はこのような方
法で行われてきた。

【００５０】本発明の拡張ＳＱＬを用いて前記多次元分
析要求を表現すると、図１２のようになる。図１０の
従来の拡張ＳＱＬと異なる点は、ＧＲＯＵＰＢＹ句に
「ＯＮＭｏｎｔｈ、ＤａｔｅＳＣＡＬＡＲ」を加
えてＭｏｎｔｈ、Ｄａｔｅの時間軸上で連続してＳＵＣ
ＨＴＨＡＴ句の条件を満たすタプルの集合をグループ
化する点と、ＳＥＬＥＣＴ句にグループ化したタプルの
時間軸上（ＯＮＭｏｎｔｈ、ＤａｔｅＳＣＡＬＡ
Ｒ）での範囲を表す属性（範囲属性）、ＳｔａｒｔＤａ
ｔｅとＥｎｄＤａｔｅを加えた点である。この図１２の
拡張ＳＱＬ文が本実施の図１に示すＯＬＡＰサーバシス
テムの対話型ユーザインタフェース１を介してユーザに
よって与えられる。また、図１の問合せ処理手段２によ
って、標準ＳＱＬおよび図４の従来の拡張ＳＱＬの構文
に対する解析に加え、本発明の拡張ＳＱＬの構文に対す
る解析が行われる。すなわち、拡張部分である「ＯＮ
Ｍｏｎｔｈ、ＤａｔｅＳＣＡＬＡＲ」の宣言によっ
て、ＧＲＯＵＰＢＹＦａｃｔ、ＰｒｏｄＮｏ、Ｄ
ａｔｅ、Ｙｅａｒでグループ化したタプルの集合をＭｏ
ｎｔｈ、ＤａｔｅのＳＣＡＬＡＲの順序で、すなわち標
準ＳＱＬのＯＲＤＥＲＢＹを行った一次元軸上で順序
付けし、そしてＳＵＣＨＴＨＡＴ句での条件が連続し
てＴｒｕｅとなるタプルの集合ごとにグループ化する。
グループ化変数Ｒで表されるタプルの集合は、ＧＲＯＵ
ＰＢＹＦａｃｔ。ＰｒｏｄＮｏ、Ｄａｔｅ。Ｙｅ
ａｒでグループ化された各グループのタプルの集合の中
で、ＡＶＧ（Ｑｕａｎｔｉｔｙ）を超えるＱｕａｎｔｉ
ｔｙを持つタプルのみで構成される。

【００５１】また、範囲属性のＳｔａｒｔＤａｔｅ、Ｅ
ｎｄＤａｔｅを表すそれぞれのＤａｔｅＫｅｙは、グル
ープ化変数Ｒの中で、最小（最大）のＭｏｎｔｈを持つ
タプルで一時グループ化し、さらにその中で最小（最
大）のＤａｔｅを持つタプルでグループ化したタプルの
属性値となる。図１１のデータが格納される本実施のＯ
ＬＡＰサーバシステムに対して図１２で示した本発明の
拡張ＳＱＬを入力すると、結果として、・１９９７年のＱｕａｎｔｉｔｙの平均値を上回ってい
たａの領域上でのＱｕａｎｔｉｔｙの平均値・１９９７年のＱｕａｎｔｉｔｙの平均値を上回ってい
たｂの領域上でのＱｕａｎｔｉｔｙの平均値・１９９８年のＱｕａｎｔｉｔｙの平均値を上回ってい
たｃの領域上でのＱｕａｎｔｉｔｙの平均値・１９９８年のＱｕａｎｔｉｔｙの平均値を上回ってい
たｄの領域上でのＱｕａｎｔｉｔｙの平均値・１９９９年のＱｕａｎｔｉｔｙの平均値を上回ってい
たｅの領域上でのＱｕａｎｔｉｔｙの平均値・１９９９年のＱｕａｎｔｉｔｙの平均値を上回ってい
たｆの領域上でのＱｕａｎｔｉｔｙの平均値の６つのデータが得られることになる。さらにそれぞれ
のグループにおいて、範囲属性ＳｔａｒｔＤａｔｅ、Ｅ
ｎｄＤａｔｅによってその時間間隔に関するデータも得
られる。

【００５２】（動作形態２）ユーザ定義集約関数を用い
た分析例を示す。図１３は、ユーザ定義集約関数を利用
した拡張ＳＱＬによる多次元分析要求の記述例を示す
図、図１４は、時間軸上で連続してＱｕａｎｔｉｔｙが
単調増加していることを条件としてグループ化されたタ
プルの集合を表すグラフの図である。動作形態１で挙げ
た多次元分析要求を少し変更して、以下の多次元分析要
求についての適用を考える。「Ｆａｃｔｔａｂｌｅで
管理されるＱｕａｎｔｉｔｙに関して。各Ｐｒｏｄｕｃ
ｔの各Ｙｅａｒごとに、Ｑｕａｎｔｉｔｙの値が連続し
て単調増加している期間ごとのＱｕａｎｔｉｔｙの平均
値を求めよ」本実施形態では、ある属性値がある次元軸
上で連続して単調増加していることを条件としてタプル
の集合を作成するユーザ定義集約関数ａｓｃｅｎｄａｎ
ｔ（）が用意されているものと仮定する。関数ａｓｃｅ
ｎｄａｎｔ（）は単調増加する対象となる属性名を入力
パラメータとして受け取り、本実施の図１のＯＬＡＰサ
ーバシステムのユーザ定義集約関数処理手段３で実装さ
れ、問合せ処理手段２によって呼び出され実行される。

【００５３】本実施の拡張ＳＱＬを用いて前記多次元分
析要求を表現すると、図１３のようになる。動作形態１
で挙げた図１２と異なる点は、ＳＵＣＨＴＨＡＴ句の
グループ化の条件式を「Ｒ．ａｓｃｅｎｄａｎｔ（Ｑｕ
ａｎｔｉｔｙ）」とした点である。「ＧＲＯＵＰＢＹ
Ｆａｃｔ、ＰｒｏｄＮｏ、Ｄａｔｅ、Ｙｅａｒ」で
グループ化された各タプルの集合はグループ化変数Ｒに
よって表されるが、その各タプルの集合を対象としてユ
ーザ定義集約関数ａｓｃｅｎｄａｎｔ（Ｑｕａｎｔｉｔ
ｙ）が評価される。加えて、図１４に示すようにａから
ｇまでのグループが作成され、これら７つのグループが
新たにグループ化変数Ｒによって表されることとなる。

【００５４】以上のように、本実施のＯＬＡＰサーバシ
ステムでは、タプルの集合に対してより複雑な処理や条
件判定を行うユーザ定義の集約関数を組み込むことによ
り、その集約関数を用いてさらに高度な多次元分析要求
を処理することが可能となる。

【００５５】（動作形態３）ステート・テーブルの宣言
と管理の動作形態を示す。図１５は、図１２の拡張ＳＱ
Ｌをステート・テーブルとして定義した例を示す図、図
１６は、図３の既存のスター・スキーマに変更を加える
ことなく図１５のステート・テーブルＳｅｑＡＶＧＳ
ｔａｔｅを追加したスキーマの図である。図１２で示し
た本実施の拡張ＳＱＬによって取得されるタプルの集合
をステートとして管理するには、本実施のＣＲＥＡＴＥ
ＳＴＡＴＥ文を用いてステート・テーブルを定義し、
それを対話型ユーザインタフェースを通して入力するこ
とになる。ステート・テーブルの名前をＳｅｑＡＶＧ
Ｓｔａｔｅとし、その副問合せ部（ＡＳ句）に図１２
の拡張ＳＱＬを記述する（図１５）。図３のスター・ス
キーマとそのデータが既に本実施のＯＬＡＰサーバシス
テムのデータベース５の中に存在したとして、図１５の
ステート・テーブルが対話型ユーザインタフェース１を
通して入力された場合、そのステート・テーブルのデー
タベースにおける位置付けは図１６に示す通りとなる。
ステート・テーブルＳｅｑＡＶＧＳａｔｅは、ファ
クト・テーブルとは別の物理的な格納構造を持つ。ま
た、既存のディメンション・テーブルのＰｒｏｄｕｃｔ
とＤａｔｅをこのＳｅｑＡＶＧＳｔａｔｅのディメ
ンションとして利用している。よって前記ディメンショ
ン・テーブルのＰｒｏｄｕｃｔとＤａｔｅが有する集約
階層を表す属性に対するビットマップ・インデックスを
そのまま利用することができる。また、ＳｅｑＡＶＧ
Ｓｔａｔｅと前記ディメンション・テーブルとの間の
ビットマップ・ジョイン・インデックスに関しては、新
規に作成することとなる。図１６のＳｅｑＡＶＧＳ
ｔａｔｅとファクト・テーブルとの間のｍｅｍｂｅｒ−
ｏｆの関係は、ステートとファクトの１対多の関係を表
している。具体的には、ステート・テーブルの定義で与
えたグループ化の条件に従ってグループ化したファクト
の集合を、ＲＩＤによってステートが管理している関係
を表している。これにより、ステートからファクトへの
ドリル・ダウンを直接的に行うことが可能となる。

【００５６】（動作形態４）ステート・テーブルの追加
定義の実施例を示す。図１７は、ステート・テーブルＳ
ｅｑＡＶＧＳｔａｔｅを利用して別のステート・テ
ーブルＳｅｑＡＶＧＤＳｔａｔｅを定義する記述
例を示す図、図１８は、ステート・テーブルＳｅｑＡ
ＶＧＤＳｔａｔｅを利用して新たにＣｉｔｙとＳａ
ｌｅｓｐｅｒｓｏｎの属性を加えたステート・テーブル
ＣｉｔｙＳａｌｅｓＰＳｅｑＡＶＧＤＳｔａ
ｔｅを定義する記述例を示す図、図１９は、テート・テ
ーブルＣｉｔｙＳａｌｅｓＰＳｅｑＡＶＧＤ
Ｓｔａｔｅを利用してＱｕａｎｔｉｔｙの月平均値を
超えるタプルでグループ化するステート・テーブルＣｉ
ｔｙＳａｌｅｓＰＳｅｑＭＡＶＧＤＳｔａｔ
ｅを定義する記述例を示す図である。ステート・テーブ
ルＳｅｑＡＶＧＳｔａｔｅを利用して、別のステー
ト・テーブルＳｅｑＡＶＧＤＳｔａｔｅを定義す
る。すなわち、ＳｅｑＡＶＧＳｔａｔｅに新たな属
性Ｄｕｒａｔｉｏｎ（期間）を加えたステートである
（図１７）。さらにステート・テーブルを追加定義す
る。図１７で定義されたステート・テーブルＳｅｑＡ
ＶＧＤＳｔａｔｅを利用したステート・テーブルＣ
ｉｔｙＳａｌｅｓＰＳｅｑＡＶＧＤＳｔａｔｅ
を定義する。すなわち、ＣｉｔｙごとＳａｌｅｓｐｅｒ
ｓｏｎごとのＳｅｑＡＶＧＤＳｔａｔｅを管理す
るステート・テーブルである。定義は図１８に示す通り
である。さらにステート・テーブルを追加定義する。グ
ループ化の方法で、Ｑｕａｎｔｉｔｙの年平均値を超え
るタプルでグループ化するのではなく、月平均の単位で
タプルの集合を作成するようにする（図１９）。

【００５７】以上のステート・テーブルの定義（図１
７、図１８、図１９）を本実施のＯＬＡＰサーバシステ
ムに入力したとする。その結果、データベース５では、
図２０に示すスキーマが展開される。図２０に示すテー
ブルがステート・テーブルである。ステート・テーブル
の間の白抜き三角の矢印はステート・テーブル間の依存
関係を表している。すなわち矢印の先のステートを利用
して、矢印の元のステートが作成される。本実施のＯＬ
ＡＰサーバシステムのデータ管理手段４はこのｂａｓｅ
ｄ−ｏｎの関係を管理し、矢印の先のステートから矢印
の元のステートの作成、および更新の反映を行う。

【００５８】（動作形態５）ステート・テーブルからフ
ァクト・テーブルのファクトの集合を特定するドリル・
ダウン操作の実施例を示す。図２０は、図１６の既存の
スキーマに変更を加えることなく図１７、図１８、図１
９のステートテーブルを追加したスキーマの図、図２１
は、ステート・テーブルＳｅｑＡＶＧＳｔａｔｅの
中でもっとも平均値の高いステートの詳細データを返却
する本実施の拡張ＳＱＬによる問合せの記述例を示す図
である。前述の多次元分析要求を発展させて、以下の要
求について考える。「Ｆａｃｔｔａｂｌｅで管理され
るＱｕａｎｔｉｔｙに関して。各Ｐｒｏｄｕｃｔの各Ｙ
ｅａｒごとに、その年のＱｕａｎｔｉｔｙの平均値を連
続して上回っていた期間ごとのＱｕａｎｔｉｔｙの平均
値を求め、そのもっとも平均値の高いグループの詳細を
リストせよ」前記多次元分析要求のうち下線を引いてい
ない部分は、前述の図１５で示したステート・テーブル
ＳｅｑＡＶＧＳｔａｔｅによって既に実現されてい
る。従って、このＳｅｑＡＶＧＳｔａｔｅを用い
て、もっとも平均値の高いステートを求めることができ
る。

【００５９】次に、その求めたステートを構成したファ
クト・テーブルのファクトを求めなければならない。ス
テートＳｅｑＡＶＧＳｔａｔｅには、そのステート
・テーブルの定義で宣言したＦｒｏｍ句の各テーブルの
タプルの集合を管理する属性ＦａｃｔとＤａｔｅを暗黙
のうちに有することにする。その暗黙の各属性には、グ
ループ化の対象となったタプルを一意に識別するＲＩＤ
を指すＲＥＦ型の値の集合が格納される。この暗黙の属
性を用いてタプルの属性値を参照するには、ポインタ表
記法の−＞を用いる。ここで、前記−＞はＳＱＬ：１９
９９で述べられている表記法であるが、ＤＢＭＳベンダ
ーによっては必ずしもこの表記法を採用しているわけで
はない。ドット表記であったり、ＤＥＲＥＦ（）などの
特別な関数表記法を用いたりさまざまである。本実施の
実装方法では、各ＤＢＭＳベンダーの表記法に従うもの
とする。前記暗黙の属性を用いて前記多次元分析要求を
満足させるＳＱＬを記述すると、図２１となる。図１１
のデータを格納する本実施のＯＬＡＰサーバシステムに
対して図２１のＳＱＬを入力すると、結果として図１１
のｄ（もっとも平均値の高いグループ）の領域上の詳細
データが返却される。

【００６０】（動作形態６）ステート・テーブルのマー
ジとジョインの実施例を示す。図２２は、ステート・テ
ーブルＳｅｑＡＶＧＳｔａｔｅの中のステートで各
Ｙｅａｒごとにマージを行う操作の記述例を示す図、図
２３は、ステート・テーブルＣｉｔｙＳａｌｅｓＰ
ＳｅｑＭＡＶＧＤＳｔａｔｅの中で各Ｙｅａｒご
とに第一四半期（４〜６月）でステートをマージする操
作の記述例を示す図、図２４は、図２８の高熱状態テー
ブルで平均体温が３７。５℃を超える高温状態同士をマ
ージする操作の記述例を示す図、図２５は、図２９の高
血圧状態テーブルで、同じ患者番号でかつ高熱状態の期
間と高血圧状態の期間が重なっている状態同士をジョイ
ンする操作の記述例を示す図である。図３０、図３１
は、マージ操作後、ジョイン操作後のステート・テーブ
ルを示す図である。本実施のＯＬＡＰサーバシステムで
は、ステートのマージ操作とステートのマージ操作とジ
ョイン操作を可能とする。マージ操作とは、単一のステ
ート・テーブルにおいて、マージの対象となる複数のス
テートからマージ後の一つのステートを作成することで
あり、マージ対象の複数のステートが管理するそれぞれ
のファクトの集合の和集合を一つのグループとしたステ
ートを作成し、かつそのグループから集約属性、範囲属
性、派生属性を再計算することである。図２２にステー
トのマージ操作の例を示す。図２２では、同じＹｅａｒ
の値を持つステート同士をマージして一つのステートを
作成し、そのステートの値を返却するものである。グル
ープ化変数が指すタプルがステートである場合は、各ス
テートの元となっているファクトの集合の和集合を求
め、その和集合によって一つのステートを作成する。こ
のとき、そのステートの各属性値は再計算される。例え
ばステート・テーブルＳｅｑＡＶＧＳｔａｔｅに
は、図１１で示されるようなａ、ｂ、ｃ、ｄ、ｅ、ｆの
６つのステートが存在したとする。図２２のＳＱＬによ
り、各Ｙｅａｒごとに（ａ、ｂ）、（ｃ、ｄ）、（ｅ、
ｆ）の３つのステートにマージされることとなる。ま
た、ＳＥＬＥＣＴＲ．＊のアスタリスク＊に含まれる
属性のうち、集約属性であるＳｅｑＡＶＧＱｔｙ、
範囲属性であるＳｔａｒｔＤａｔｅ、ＥｎｄＤａｔｅが
この（ａ、ｂ）、（ｃ、ｄ）、（ｅ、ｆ）の新たなグル
ープのタプルの集合を元にして再計算される。図２３の
ＳＱＬは、ステート・テーブルＣｉｔｙＳａｌｅｓＰ
ＳｅｑＭＡＶＧＤＳｔａｔｅのステートに対
し、各Ｙｅａｒごとの第一四半期（４〜６月）でマージ
する例である。Ｒ．＊のアスタリスク＊に含まれるグル
ープ化属性Ｍｏｎｔｈは、特別な定数値であるＡＬＬを
出力する（文献［３］）。

【００６１】図２８で表されるステート・テーブルに対
するマージ操作の例を示す。ステート・テーブル高熱状
態に対して、平均体温が３７．５℃を超えるステート同
士をマージするＳＱＬの例は図２４であり、その実行結
果は図３０に示す通りである。次にジョイン操作につい
て説明する。ジョイン操作とは、複数のステート・テー
ブルを通常のＳＱＬと同様のジョインを行った後、各ス
テートと関係するファクトの和集合を新たなグループと
してステートを作成することである。このときその新た
なグループを元にしてステートの集約属性、範囲属性、
派生属性の再計算も行われる。

【００６２】図２８、図２９で表されるステート・テー
ブルをジョインする例を示す。双方のステート・テーブ
ルの各ステートが同じ患者番号を持ち、かつステート同
士の期間が重なっていることを条件としてジョインＳＱ
Ｌの例は図２５であり、その実行結果は図３１に示す通
りである。

【００６３】

【発明の効果】本発明のＯＬＡＰサーバシステムを多次
元分析に利用し得られる第一の効果は、対話型（ＳＱＬ
非カーソル型）の多次元要求で、時間や座標などの順序
付け可能属性の値の連続した領域での条件判定によって
タプルをグループ化しその集約値を求めることが可能に
なったことである。第二の効果は、タプルの集合に対し
てより複雑な処理や条件判定を行うユーザ定義の集約関
数を用意に組み込むことが可能となり、その集約関数を
用いてさらに高度な多次元分析要求を処理することが可
能となったことである。第三の効果は、第一および第二
の効果で述べたグループ化の方法に従って集約した結果
を、グループ化属性、集約属性、範囲属性、派生属性、
ファクトグループ参照属性の５種類の属性を選択的に有
するテーブルを多次元分析の事前に用意し、その結果、
多次元分析処理の応答時間を短縮することが可能になっ
たことである。第四の効果は、第三の効果で述べたテー
ブルのタプルからグループ化前のタプルの集合を求める
ドリル・ダウンの操作で、前記タプルの集合のＲＩＤを
前記テーブルの各タプルに静的に保持させることによっ
て直接的に求めることを可能にしたことである。第五の
効果は、第三の効果で述べたテーブルの定義が、既存の
スター・スキーマに変更を与えずに追加のみで拡張する
ことができることである。第六の効果は、第三の効果で
述べたテーブルのタプルに対する操作として、従来のス
ター・スキーマに基づくロールアップやドリル・ダウン
に加えて、マージおよびジョインの操作を加えることが
できたことである。

【００６４】

【図面の簡単な説明】

【図１】本発明に係る対話分析的データベースシステム
及び対話的分析プログラムを記録した記録媒体の一実施
の形態における構成を示すブロック図である。

【図２】文献［１］より引用したＭｕｌｔｉｄｉｍｅｎ
ｓｉｏｎａｌｄａｔａを示す図である。

【図３】文献［１］より引用したＳｔａｒＳｃｈｅｍ
ａを示す図である。

【図４】従来の技術を説明するための、文献［２］、
［３］より引用した（一部修正を加えた）拡張ＳＱＬの
構文を示す図である。

【図５】本発明に係わる多次元データを二次元上の連続
領域での条件判定によってグループ化する例を示した図
である。

【図６】本発明に係る対話分析的データベースシステム
及び対話的分析プログラムを記録した記録媒体の一実施
の形態における多次元分析要求を入力するためにユーザ
が記述する拡張ＳＱＬの構文を示す図である。

【図７】本発明に係る対話分析的データベースシステム
及び対話的分析プログラムを記録した記録媒体の一実施
の形態における拡張ＳＱＬのＧＲＯＵＰＢＹ句、ＳＵ
ＣＨＴＨＡＴ句、ＨＡＶＩＮＧ句の構文を示す図であ
る。

【図８】本発明に係る対話分析的データベースシステム
及び対話的分析プログラムを記録した記録媒体の一実施
の形態におけるファクトの集合を管理するファクトグル
ープ参照属性を有するステート・テーブルを示す図であ
る。

【図９】動作形態１において対照のために供される従来
技術の標準ＳＱＬによる多次元分析要求の記述例を示す
図である。

【図１０】動作形態１において対照のために供される従
来技術の拡張ＳＱＬによる多次元分析要求の記述例を示
す図である。

【図１１】図２および図３で示される多次元データモデ
ルに従う多次元データで、ＰｒｏｄＮｏ＝００１の１９
９７〜１９９９年のＱｕａｎｔｉｔｙの値を示すグラフ
の図である。

【図１２】動作形態１における拡張ＳＱＬによる多次元
分析要求の記述例を示す図である。

【図１３】動作形態２におけるユーザ定義集約関数を利
用した拡張ＳＱＬによる多次元分析要求の記述例を示す
図である。

【図１４】動作形態２における時間軸上で連続してＱｕ
ａｎｔｉｔｙが単調増加していることを条件としてグル
ープ化されたタプルの集合を表すグラフの図である。

【図１５】動作形態３における図１２の拡張ＳＱＬをス
テート・テーブルとして定義した例を示す図である。

【図１６】動作形態３における図３の既存のスター・ス
キーマに変更を加えることなく図１５のステート・テー
ブルＳｅｑＡＶＧＳｔａｔｅを追加したスキーマの
図である。

【図１７】動作形態４におけるステート・テーブルＳｅ
ｑＡＶＧＳｔａｔｅを利用して別のステート・テー
ブルＳｅｑＡＶＧＤＳｔａｔｅを定義する記述例
を示す図である。

【図１８】動作形態４におけるステート・テーブルＳｅ
ｑＡＶＧＤＳｔａｔｅを利用して新たにＣｉｔｙ
とＳａｌｅｓｐｅｒｓｏｎの属性を加えたステート・テ
ーブルＣｉｔｙＳａｌｅｓＰＳｅｑＡＶＧＤ
Ｓｔａｔｅを定義する記述例を示す図である。

【図１９】動作形態４におけるテート・テーブルＣｉｔ
ｙＳａｌｅｓＰＳｅｑＡＶＧＤＳｔａｔｅ
を利用してＱｕａｎｔｉｔｙの月平均値を超えるタプル
でグループ化するステート・テーブルＣｉｔｙＳａｌ
ｅｓＰＳｅｑＭＡＶＧＤＳｔａｔｅを定義する記
述例を示す図である。

【図２０】動作形態５における図１６の既存のスキーマ
に変更を加えることなく図１７、図１８、図１９のステ
ートテーブルを追加したスキーマの図である。

【図２１】動作形態５におけるステート・テーブルＳｅ
ｑＡＶＧＳｔａｔｅの中でもっとも平均値の高いス
テートの詳細データを返却する本発明の拡張ＳＱＬによ
る問合せの記述例を示す図である。

【図２２】動作形態６におけるステート・テーブルＳｅ
ｑＡＶＧＳｔａｔｅの中のステートで各Ｙｅａｒご
とにマージを行う操作の記述例を示す図である。

【図２３】動作形態６におけるステート・テーブルＣｉ
ｔｙＳａｌｅｓＰＳｅｑＭＡＶＧＤＳｔａｔ
ｅの中で各Ｙｅａｒごとに第一四半期（４〜６月）でス
テートをマージする操作の記述例を示す図である。

【図２４】動作形態６における図２８の高熱状態テーブ
ルで平均体温が３７．５℃を超える高温状態同士をマー
ジする操作の記述例を示す図である。

【図２５】動作形態６における図２９の高血圧状態テー
ブルで、同じ患者番号でかつ高熱状態の期間と高血圧状
態の期間が重なっている状態同士をジョインする操作の
記述例を示す図である。

【図２６】本発明の例題のデータとして用いる、二次元
軸Ｘ、Ｙとその上のｍｅｓｈの関係を表すテーブルを示
す図である。

【図２７】本発明の例題のデータとして用いる、患者の
体温−血圧テーブルを示す図である。

【図２８】本発明の例題のデータとして用いる、高熱状
態テーブルを示す図である。

【図２９】本発明の例題のデータとして用いる、高血圧
状態テーブルを示す図である。

【図３０】動作形態６の結果を示す、マージ操作後のス
テート・テーブルを示す図である。

【図３１】動作形態６の結果を示す、ジョイン操作後の
ステート・テーブルを示す図である。

【符号の説明】

１対話型ユーザインタフェース２問合せ処理手段３ユーザ定義集約関数処理手段４データ管理手段５データベース

Claims

【特許請求の範囲】

【請求項１】対話型ユーザインタフェースと、このイン
ターフェースで使用される対話型問合せ言語と、この問
合せ言語の構文を解釈する問合せ処理手段と、前記問合
せ言語の構文解釈に従ってデータを運用管理するデータ
管理手段と、前記データを格納するデータベースとを備
え、データを対話的かつ多次元分析的に運用管理するＯ
ＬＡＰサーバシステムである対話分析的データベースシ
ステムにおいて、順序付け可能属性を有する一以上の次
元の順序による多次元データの隣接概念に基づく多次元
分析要求とその結果を管理する分析結果管理要求とを記
述する拡張された対話型問合せ言語と、この拡張された
対話型問合せ言語の構文を解釈する拡張された問合せ処
理手段と、この構文解釈に従ってデータを運用管理する
データ管理手段とを備えたことを特徴とする対話分析的
データベースシステム。
【請求項２】前記データ管理手段が多次元データを表現
する各テーブルとそのスター・スキーマによりデータを
運用管理すると共に、前記拡張された対話型問合せ言語
が対話型の拡張ＳＱＬであることを特徴とする請求項１
に記載の対話分析的データベースシステム。
【請求項３】前記多次元分析要求が、標準ＳＱＬの条件
判定に加えて前記隣接概念による連続した領域であるこ
とを条件に前記テーブルのタプルをグループ化し集約す
る連続集約要求を含むことを特徴とする請求項２に記載
の対話分析的データベースシステム。
【請求項４】前記多次元分析要求が、前記連続集約要求
により生成された集約データに対し、ユーザ定義集約関
数によりその集約値を求める要求を含むことを特徴とす
る請求項３に記載の対話分析的データベースシステム。
【請求項５】前記拡張ＳＱＬが、グループ化属性、集約
属性、範囲属性、派生属性、ファクトグループ参照属性
の５種類の属性を選択的に有するテーブル定義を有し、
前記分析結果管理要求が、前記集約結果を前記拡張ＳＱ
Ｌで定義したテーブルとしてデータベースに格納し管理
する要求を含むことを特徴とする請求項４に記載の対話
分析的データベースシステム。
【請求項６】データを対話的かつ多次元分析的に運用管
理するために対話型ＳＱＬ（ＳＱＬ非カーソル型）を解
釈し実行するプログラムを記録した対話的分析プログラ
ムを記録した記録媒体であって、対応する拡張ＳＱＬを
解釈し、順序付け可能属性を有する一以上の次元の順序
によるレコードの隣接概念に基づいてデータを集約し新
たなデータとして運用管理可能にするプログラムを記録
したことを特徴とする対話的分析プログラムを記録した
記録媒体。