特許 6559892 データキューブのデータの記憶及び検索

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6559892

(24)【登録日】2019年7月26日

(45)【発行日】2019年8月14日

(54)【発明の名称】データキューブのデータの記憶及び検索

(51)【国際特許分類】

   G06F 16/28 20190101AFI20190805BHJP

   G06F 16/22 20190101ALI20190805BHJP

【ＦＩ】

   G06F16/28

   G06F16/22

【請求項の数】18

【全頁数】35

(21)【出願番号】特願2018-521362(P2018-521362)

(86)(22)【出願日】2016年11月16日

(65)【公表番号】特表2018-538606(P2018-538606A)

(43)【公表日】2018年12月27日

(86)【国際出願番号】US2016062258

(87)【国際公開番号】WO2017091410

(87)【国際公開日】20170601

【審査請求日】2018年6月1日

(31)【優先権主張番号】14/949,391

(32)【優先日】2015年11月23日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】509123208

【氏名又は名称】アビニシオ テクノロジー エルエルシー

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】プロコプス，ロイ

(72)【発明者】

【氏名】トラハン，デイビッド

【審査官】 早川 学

(56)【参考文献】

【文献】 特表２０１０−５０８６０６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／０１２６１４３（ＵＳ，Ａ１）

【文献】 田中聡，ドリルスルーによるＨｙｂｒｉｄ ＯＬＡＰの実現，情報処理学会研究報告，社団法人情報処理学会，１９９８年 ７月 ８日，第98巻、第57号，pp.157〜164

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １６／２８

Ｇ０６Ｆ １６／２２

(57)【特許請求の範囲】

【請求項1】

１つ又は複数のフラットファイルにデータキューブのデータを記憶するコンピュータ実施方法であって、前記フラットファイルは有形の非一時的コンピュータ可読媒体に記憶され、前記方法は、
１組のデータレコードを受信することであって、前記１組のデータレコードは少なくとも２つの次元を有し、前記データレコードの少なくとも幾つかはそれぞれ、前記少なくとも２つの次元のそれぞれに各データ値を含む、受信することと、
基数により順序づけられた１組のグループ化されたデータレコードを生成することであって、前記生成することは、
前記少なくとも２つの次元のうちの第１の次元のデータ値に従って、前記データレコードをサブセットにグループ化することであって、前記第１の次元で可能なデータ値数は、第２の次元で可能なデータ値数より少ない、グループ化すること、
前記第１の次元の前記データ値及び記憶基準に従って、前記グループ化されたデータレコードの前記サブセットを配置すること、及び
前記グループ化されたデータの各サブセットのデータレコードが前記第２の次元の前記値によりソートされるように、前記少なくとも２つの次元のうちの前記第２の次元のデータ値に従って、前記グループ化されたデータレコードの前記サブセットの前記データレコードを配置すること
を含む、生成することと、
前記１組の前記グループ化されたデータレコードを含む少なくとも１つのフラットファイルを生成し記憶することと
を含み、
前記グループ化されたデータレコードのうちの特定のデータレコードは、要求に応答して前記特定のデータレコードのデータを識別するのに使用することができる主キーを含む、方法。

【請求項2】

前記主キーは、前記特定のデータレコードの前記データ値のうちの少なくとも幾つかを含み、前記主キーは、前記特定のデータレコードの少なくとも２つの次元の少なくとも１つの特徴から計算される要素を含む、請求項１に記載の方法。

【請求項3】

前記主キーの前記計算される要素は、１つ又は複数の詳細レベルのスカラー表現を含む詳細マスクであり、各詳細レベルは、前記データレコードの次元の階層に対応し、前記少なくとも２つの次元の前記少なくとも１つの特徴は、前記２つの次元のそれぞれで、前記階層の特定のレベルにおけるデータの存在を含む、請求項２に記載の方法。

【請求項4】

前記データレコードのサブセットへのグループ化は、前記詳細マスクに従って前記データレコードをソートすることを含む、請求項３に記載の方法。

【請求項5】

少なくとも２つの次元を含む階層を含み、前記少なくとも２つの次元のうちの第１の次元は、前記階層の第１のレベルを表し、前記少なくとも２つの次元のうちの第２の次元は、前記第１のレベルよりも低い前記階層の第２のレベルを表す、請求項１〜４のいずれか一項に記載の方法。

【請求項6】

クエリを処理することであって、それにより、前記少なくとも１つのフラットファイルに記憶された前記データレコードのうちの１つ又は複数にアクセスする、処理することを含み、前記クエリは前記第２の次元に対する制約を含み、前記処理することは、
前記第２の次元に対する前記制約に基づいて、前記第１の制約に対する制約を識別することと、
前記識別された制約を前記クエリに追加することと
を含む、請求項５に記載の方法。

【請求項7】

クエリを処理して、前記少なくとも１つのフラットファイルに記憶された前記データレコードのうちの１つ又は複数にアクセスする、処理することを含み、前記クエリは、前記１組のデータレコードの少なくとも１つの次元に対する少なくとも１つの制約を含む、請求項１〜６のいずれか一項に記載の方法。

【請求項8】

前記クエリを処理することは、前記クエリの少なくとも１つの詳細マスクを計算することであって、前記詳細マスクは１つ又は複数の詳細レベルのスカラー表現を含み、各詳細レベルは、前記フラットファイルに記憶された前記データレコードの次元の階層に対応する、計算することと、前記計算された詳細マスクを使用することであって、それにより、前記クエリに応答して１つ又は複数のデータレコードを識別する、使用することとを含む、請求項７に記載の方法。

【請求項9】

前記クエリを処理することは、前記少なくとも２つの次元のうちの１つ又は複数の最小値及び最大値を計算することを含む、請求項７に記載の方法。

【請求項10】

前記クエリを処理することは、前記クエリが反復最適化の候補であると判断することと、サブクエリの少なくとも２回の反復を実行して、前記クエリを処理することとを含む、請求項７に記載の方法。

【請求項11】

前記少なくとも１つのフラットファイルに記憶された前記データレコードのうちの１つ又は複数にアクセスする要求を受信することを含み、前記要求は、前記フラットファイルに関連する識別子と、前記フラットファイル内の開始ロケーションを指定する第１の主キーと、前記フラットファイル内の終了ロケーションを指定する第２の主キーとを含む、請求項１〜１０のいずれか一項に記載の方法。

【請求項12】

ＳＱＬクエリを処理して、前記少なくとも１つのフラットファイルに記憶された前記データレコードのうちの１つ又は複数にアクセスすることを含む、請求項１〜１１のいずれか一項に記載の方法。

【請求項13】

前記グループ化されたデータレコードは、ブロックの形態で前記少なくとも１つのフラットファイルに記憶され、各ブロックは前記データレコードのうちの１つ又は複数を含み、
前記方法は、
前記ブロックのそれぞれの１つ又は複数のエントリを含むインデックスを生成すること
を含み、
前記ブロックのそれぞれのエントリの前記１つ又は複数は、前記各ブロックを識別する主キーフィールドと、前記少なくとも１つのフラットファイル内の前記各ブロックの記憶ロケーションを識別するロケーションフィールドとを含む、請求項１〜１２のいずれか一項に記載の方法。

【請求項14】

主キー値を受信することと、
前記受信した主キー値に基づいて、前記主キーフィールド及び前記ロケーションフィールドを使用することにより、前記受信した主キー値を含む主キー値範囲に対応するデータレコードを含むブロックのうちの１つの記憶ロケーションを識別することと
を含む、請求項１〜１３のいずれか一項に記載の方法。

【請求項15】

前記少なくとも２つの次元の中の異なる詳細レベルの１つ又は複数の値を事前に計算することであって、前記事前に計算される値は、次元の異なる詳細レベルで集計される尺度を表し、前記グループ化されたデータレコードは、前記事前に計算される値のうちの少なくとも幾つかを含む、請求項１〜１４のいずれか一項に記載の方法。

【請求項16】

データキューブのデータを１つ又は複数のフラットファイルに記憶することが可能なデータ処理システムであって、
１組のデータレコードを受信することであって、前記１組のデータレコードは少なくとも２つの次元を有し、前記データレコードの少なくとも幾つかはそれぞれ、前記少なくとも２つの次元のそれぞれに各データ値を含む、受信することと、
基数により順序づけられた１組のグループ化されたデータレコードを生成することであって、前記生成することは、
前記少なくとも２つの次元のうちの第１の次元のデータ値に従って、前記データレコードをサブセットにグループ化することであって、前記第１の次元で可能なデータ値数は、第２の次元で可能なデータ値数より少ない、グループ化すること、
前記第１の次元の前記データ値及び記憶基準に従って、前記グループ化されたデータレコードの前記サブセットを配置すること、及び
前記グループ化されたデータの各サブセットのデータレコードが前記第２の次元の前記値によりソートされるように、前記少なくとも２つの次元のうちの前記第２の次元のデータ値に従って、前記グループ化されたデータレコードの前記サブセットの前記データレコードを配置すること
を含む、生成することと、
前記１組の前記グループ化されたデータレコードを含む少なくとも１つのフラットファイルを生成し記憶することと
を含む動作を実行するように構成され、
前記グループ化されたデータレコードのうちの特定のデータレコードは、要求に応答して前記特定のデータレコードのデータを識別するのに使用することができる主キーを含む、システム。

【請求項17】

データ処理システムがデータキューブのデータを１つ又は複数のフラットファイルに記憶できるようにする命令を記憶する非一時的コンピュータ可読記憶装置であって、前記命令は、前記データ処理システムに、
１組のデータレコードを受信することであって、前記１組のデータレコードは少なくとも２つの次元を有し、前記データレコードの少なくとも幾つかはそれぞれ、前記少なくとも２つの次元のそれぞれに各データ値を含む、受信することと、
基数により順序づけられた１組のグループ化されたデータレコードを生成することであって、前記生成することは、
前記少なくとも２つの次元のうちの第１の次元のデータ値に従って、前記データレコードをサブセットにグループ化することであって、前記第１の次元で可能なデータ値数は、第２の次元で可能なデータ値数より少ない、グループ化すること、
前記第１の次元の前記データ値及び記憶基準に従って、前記グループ化されたデータレコードの前記サブセットを配置すること、及び
前記グループ化されたデータの各サブセットのデータレコードが前記第２の次元の前記値によりソートされるように、前記少なくとも２つの次元のうちの前記第２の次元のデータ値に従って、前記グループ化されたデータレコードの前記サブセットの前記データレコードを配置すること
を含む、生成することと、
前記１組の前記グループ化されたデータレコードを含む少なくとも１つのフラットファイルを生成し記憶することと
を含む動作を実行させ、
前記グループ化されたデータレコードのうちの特定のデータレコードは、要求に応答して前記特定のデータレコードのデータを識別するのに使用することができる主キーを含む、非一時的コンピュータ可読記憶装置。

【請求項18】

データキューブのデータを１つ又は複数のフラットファイルに記憶することが可能なデータ処理システムであって、
１組のデータレコードを受信する手段であって、前記１組のデータレコードは少なくとも２つの次元を有し、前記データレコードの少なくとも幾つかはそれぞれ、前記少なくとも２つの次元のそれぞれに各データ値を含む、受信する手段と、
基数により順序づけられた１組のグループ化されたデータレコードを生成する手段であって、前記生成することは、
前記少なくとも２つの次元のうちの第１の次元のデータ値に従って、前記データレコードをサブセットにグループ化することであって、前記第１の次元で可能なデータ値数は、第２の次元で可能なデータ値数より少ない、グループ化すること、
前記第１の次元の前記データ値及び記憶基準に従って、前記グループ化されたデータレコードの前記サブセットを配置すること、及び
前記グループ化されたデータの各サブセットのデータレコードが前記第２の次元の前記値によりソートされるように、前記少なくとも２つの次元のうちの前記第２の次元のデータ値に従って、前記グループ化されたデータレコードの前記サブセットの前記データレコードを配置すること
を含む、生成する手段と、
前記１組の前記グループ化されたデータレコードを含む少なくとも１つのフラットファイルを生成し記憶する手段と
を含む動作を実行するように構成され、
前記グループ化されたデータレコードのうちの特定のデータレコードは、要求に応答して前記特定のデータレコードのデータを識別するのに使用することができる主キーを含む、データ処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
本願は、例えば、高速データ処理及びネットワーク通信における用途でデータキューブのデータを記憶し検索するデータ構造及び方法に関する。

【背景技術】

【0002】

背景
データキューブは、複数の次元を有するデータの集まりである。次元は、対象となる属性である。したがって、データキューブに記憶されたデータは、属性のうちの１つ又は複数の値を有することができる。

【発明の概要】

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

【0003】

概要
特に、本明細書では、１つ又は複数のフラットファイルにデータキューブのデータを記憶する技法について記載する。データキューブは、複数の次元に適用される基準に基づいて照会することができるデータの集まりである。データキューブは、データ値の二次元、三次元、又はそれよりも高次元のアレイであり得る。フラットファイルは、レコード間に構造化された関係を有さない、データレコード等のデータの集まりである。ファイルはフラットであり、ファイルがインデックス付けのための構造を有さないことがあり得ることを意味する。フラットファイルは、例えば、プレーンテキストファイル又はバイナリファイルであることができる。フラットファイルは、有形の非一時的コンピュータ可読媒体に記憶することができる。本技法は、１組のデータレコードを受信することであって、１組のデータレコードは少なくとも２つの次元を有し、データレコードの少なくとも幾つかはそれぞれ、少なくとも２つの次元のそれぞれに各データ値を含む、受信することと、基数により順序づけられた１組のグループ化されたデータレコードを生成することであって、生成することは、少なくとも２つの次元のうちの第１の次元のデータ値に従って、データレコードをサブセットにグループ化することであって、第１の次元で可能なデータ値数は、第２の次元で可能なデータ値数より少ない、グループ化すること、第１の次元のデータ値及び記憶基準に従って、グループ化されたデータレコードのサブセットを配置すること、及びグループ化されたデータの各サブセットのデータレコードが第２の次元の値によりソートされるように、少なくとも２つの次元のうちの第２の次元のデータ値に従って、グループ化されたデータレコードのサブセットのデータレコードを配置することを含む、生成することと、１組のグループ化されたデータレコードを含む少なくとも１つのフラットファイルを生成し記憶することとを含み、グループ化されたデータレコードのうちの特定のデータレコードは、要求に応答して特定のデータレコードのデータを識別するのに使用することができる主キーを含む。

【0004】

クエリを処理して、データキューブのデータにアクセスする技法も記載する。データは、有形の非一時的コンピュータ可読媒体に記憶することができる。本技法は、クエリを受信することと、クエリに基づいて、データレコードを記憶しているデータキューブを識別することと、クエリの少なくとも１つの詳細マスクを計算することであって、詳細マスクは１つ又は複数の詳細レベルの表現を含み、各詳細レベルはデータレコードの次元の階層に対応し、少なくとも２つの次元のうちの第１の次元に可能なデータ値数は、第２の次元に可能なデータ値数よりも少ない、計算することと、クエリに応答して、計算された詳細マスクを使用して、リレーショナルデータベース以外のシステムから１つ又は複数のデータレコードを検索することを含む。

【0005】

これらの技法は、方法、システム、及び／又はコンピュータ可読記憶装置に記憶されたコンピュータプログラム製品として含め、幾つかの方法で実施することができる。

【0006】

これらの技法の態様は、以下の利点の１つ又は複数を含む。データキューブに記憶されたデータは、特に高速ネットワーク通信に有用な、速度を最大化し、必要な処理能力量を最小化する方法でアクセスすることができる。例えば、インデックス圧縮フラットファイル（ＩＣＦＦ）を使用して、データキューブのデータを記憶することができる。データは、ＩＣＦＦに書き込まれた後、変更されないため、ロック技法を使用せずにデータをＩＣＦＦから読み出すことができる。さらに、データは、ＩＣＦＦに書き込まれた後、変更されないため、古いデータにより使用されていたリソース（例えば、記憶空間）が、他の目的で必要になる場合、古いデータを容易に識別し破棄することができる。さらに、ＩＣＦＦ内のデータはデータファイルから直接読み出すことができるため、ＩＣＦＦ内のデータは潜在的に、リレーショナルデータベース管理システム等の中間システムが読み出しコマンドを実行する必要がある技法よりも素早く読み出すことができる。さらに、ＩＣＦＦ内のデータは通常、圧縮されるため、データが使用する記憶空間は、他の技法を使用して記憶されるデータよりも少なくし得る。さらに、ＩＣＦＦに対して実行される読み出し動作数は、データを特定の方法でグループ化することにより最小化することができる。

【図面の簡単な説明】

【0007】

【図1A】データキューブの図表現を示す。

【図1B】データキューブの図表現を示す。

【図1C】データキューブの図表現を示す。

【図1D】データキューブの図表現を示す。

【図2】レコード記憶・検索システムを示す。

【図3】図２のシステムにより記憶されたインデックス圧縮フラットファイル（ＩＣＦＦ）内のレコードを管理する例を示す。

【図4】ＩＣＦＦのデータレコードの例を示す。

【図5A】主キーに従ってソートされたデータレコードサンプルを表す表の例を示す。

【図5B】主キーに従ってソートされたデータレコードサンプルを表す表の例を示す。

【図5C】主キーに従ってソートされたデータレコードサンプルを表す表の例を示す。

【図6】関連する次元値を特定するコンセンサスの例を示す。

【図7】データ処理システムの例を示す。

【図8】フローチャートである。

【図9】フローチャートである。

【発明を実施するための形態】

【0008】

様々な図面中の同様の参照符号は同様の要素を示す。

【0009】

説明
データキューブ（例えば、オンライン分析処理キューブ又はＯＬＡＰキューブ）は、インデックス圧縮フラットファイル（ＩＣＦＦ：index compressed flat file）に記憶することができ、データキューブに記憶されたデータは照会することができる。データキューブは、複数の次元に適用される基準に基づいて照会することができるデータの集まりである。データキューブは、データ値の二次元、三次元、又はそれよりも高次元のアレイであり得る。次元はデータのカテゴリであり、データの集まりは、任意の数の次元の値を有することができる。例えば、顧客のステータス、性別、及び場所が次元である顧客データを記憶した記憶媒体では、クエリは、アクティブであり、女性であり、且つマサチューセッツ州に住んでいる顧客又は任意の性別の非アクティブであり、且つボストン市に住んでいる顧客を記述したデータのリターンを指定することができる。この例では、場所は、１つの次元ではなく複数の次元の階層であることができ、例えば、場所は、州、市、及び郵便番号をそれぞれ表す複数の次元を含むことができる。複数の次元を含む１つの次元は一般に、本明細書では階層と呼ばれることがある。２つ以上の次元の値をそれぞれ含む複数の組のデータは一緒に、データキューブと呼ぶことができる。言い換えれば、データキューブは、２つ以上の次元を有するデータの論理モデルであり得る。

【0010】

データキューブ内のデータは、データがＩＣＦＦフォーマットで記憶される場合、効率的にアクセスすることができる。ＩＣＦＦとは、データが、通常、圧縮される一連のフラットファイルに書き込まれるデータフォーマットである。データがファイルの１つに書き込まれると、そのデータは変更されない。ＩＣＦＦに従ってフォーマットされたファイルの集まりは、ＩＣＦＦと略称されることがある。ＩＣＦＦはリレーショナルデータベースではない。ＩＣＦＦとは対照的に、リレーショナルデータベースは、表が互いの間に構造化された関係を有するように表に構成されたデータレコードの集まりである。リレーショナルデータベースは通常、ＲＤＢＭＳと略称されることがあるリレーショナルデータベース管理システムにより管理される。

【0011】

ＩＣＦＦの使用には、リレーショナルデータベース等の別のデータ記憶技法の使用よりも優れた利点があり得る。例えば、データは、ＩＣＦＦに書き込まれた後、変更されないため、ロック技法を使用せずにデータをＩＣＦＦから読み出すことができ、その理由は、データが特定の部分から読み出されるのと同時に、他のエンティティがＩＣＦＦのその部分に書き込むことがないためである。したがって、ＩＣＦＦを使用しない場合には時間及び処理能力がかかるロックを設定せずに又はＩＣＦＦを使用しない場合には待ち時間を増大させる、ロックの解放を待つことなく、ＩＣＦＦにデータを読み書きすることができる。別の例として、データは、ＩＣＦＦに書き込まれた後、変更されないため、古いデータにより使用されていたリソース（例えば、記憶空間）が、他の目的で必要になる場合、古いデータを容易に識別し破棄することができる。さらに、ＩＣＦＦ内のデータはデータファイルから直接読み出すことができるため、ＩＣＦＦ内のデータは潜在的に、リレーショナルデータベース管理システム等の中間システムが読み出しコマンドを解釈し実行する必要がある技法よりも素早く読み出すことができる。さらに、ＩＣＦＦ内のデータは通常、圧縮されるため、データが使用する記憶空間は、他の技法を使用して記憶されるデータよりも少なくし得る。

【0012】

ＩＣＦＦ内のデータは主キー（ソートキー又はキューブソートキーと呼ばれることがある）に基づいてアクセスすることができる。主キーは、ＩＣＦＦ内のデータセットのロケーションに対応する一意の値であり、対応するデータセットにアクセスするのに使用することができる。このようにして、主キーは、ＩＣＦＦに記憶されたデータへのインデックスとして機能する。ＩＣＦＦに記憶された一意の各レコードは、主キーに一意の値を有する。例えば、ＩＣＦＦ内の各レコードは、１つのデータをそれぞれ記憶するフィールドの集まりであり得、フィールドの１つは、レコードの主キーを記憶するためのものであることができる。レコード内のフィールドの幾つかは、他のレコード内の対応するフィールドと同じデータを含み得、一方、各レコードの主キーは一意である。例えば、顧客を表す複数のレコードは、全てのレコード内のデータが「女性」である「性別」と呼ばれるフィールドを有し得るが、それらのレコードはそれぞれ、「主キー」フィールドにそれ自体のそれぞれの一意の値を有する。レコードの主キーは、時により、主キーがそれぞれのレコードにとって一意である可能性が高い限り、レコードの１つ又は複数のフィールドからのデータを含むことができる。

【0013】

データは、１つのクエリに対して、データレコードの連続したグループが応答する可能性の高さに基づいて、データを一緒にグループ化するようにＩＣＦＦ内に記憶することができる。フラットファイルは、レコード間に構造化された関係を有さない、データレコード等のデータの集まりである。これとは対照的に、リレーショナルデータベース管理システムにより記憶されるデータは通常、レコード間に構造化された関係を有するレコードを含む。ＩＣＦＦはフラットファイルであるため、各エントリは、各ファイル内の指定されたロケーションからデータを読み出すことによりアクセスされる。さらに、データは、主キーを使用して、その主キーに対応するレコードのＩＣＦＦ内のロケーションを識別することができるように、ＩＣＦＦ内に配置することができる。例えば、ＩＣＦＦ内のデータにアクセスするように構成された機器は、主キーのインデックス及びＩＣＦＦ内の対応するロケーションを記憶することができる。このようにして、主キーを含むクエリを機器に提出することができ、対応するデータを返すことができる。しかし、クエリの提出及び処理には、一度に多くのレコードにアクセス中である場合、データのアクセス及び検索を遅くするおそれがある量のデータ処理オーバーヘッドを必要とする。

【0014】

特定のクエリに応答するデータが、ＩＣＦＦ内で連続して一緒にグループ化される場合、１つの範囲のデータロケーションにアクセスすることによりデータをＩＣＦＦから検索することができる。さらに、主キーが、多くの場合に複数の隣接するレコードに一度にアクセスできるようにするように選ばれる場合、それらの場合でシステムのデータ検索効率は改善する。これとは対照的に、特定のクエリに応答するデータが一緒にグループ化されない場合、データを検索しているエンティティは、複数の範囲のデータロケーションにアクセスする必要があり、データ検索を遅くする。本明細書に記載されるシステムは、クエリに応答する複数のレコードがＩＣＦＦ内で一緒にグループ化され、したがって、１つの範囲（又は比較的少数の範囲）のデータロケーションにアクセスすることで検索することができる可能性を高めるように選ばれた主キーを使用する。ＩＣＦＦの例は、「Managing Storage of Individually Accessible Data Units」という名称の米国特許第８，２２９，９０２号、「Managing Operations on Stored Data Units」という名称の米国特許出願第２０１４／０２５８６５０号、これもまた「Managing Operations on Stored Data Units」という名称の米国特許出願第２０１４／０２５８６５１号、及び「Managing Operations on Stored Data Units」という名称の米国特許出願第２０１４／０２５８６５２号に更に詳細に記載されており、これらは全て参照により本明細書に援用される。

【0015】

データキューブ概説
図１Ａは、データキューブ１００の図表現を示す。データキューブは、互いに積み重ねられた複数のテーブルと考えることができる。「キューブ」という言葉は他の場合、データキューブが三次元を有することを暗黙的に示すが、データキューブは任意の数の次元を有することができる。この例では、データキューブは５つの次元を有する：性別、顧客ステータス、州、市、及び郵便番号。しかし、性別、顧客ステータス、及び州の次元のみが、データキューブ１００のこの特定の表現に示されている。

【0016】

データキューブの次元は階層に編成される。この例では、データキューブは３つの階層を有する：性別１０２、顧客ステータス１０４、及び場所１０６。場所階層１０６は、州、市、及び郵便番号の次元を含む。性別階層１０２は性別次元のみを含む。顧客ステータス階層１０４は顧客ステータス次元のみを含む。階層の次元のみ（例えば、性別及び顧客ステータス）を表す次元は、非階層次元と呼ばれることがある。

【0017】

各次元は１つ又は複数の可能な値を有する。例えば、性別次元は、「男性」、「女性」、及び「指定なし」を可能な値として有し、顧客ステータス次元は「非アクティブ」、「アクティブ」、及び「好ましい」を可能な値として有し、州次元は５０の米国の州の略称を可能な値として有し、市次元は米国の全ての市を可能な値として有し、郵便番号次元は米国の全ての郵便番号を可能な値として有する。幾つかの例では、本明細書に記載されるデータキューブは、より多くの次元を追加して（例えば、国次元を追加することにより）より詳細な情報を記憶できるようにするように拡張することができる。

【0018】

ユーザは、照会技法に従ってデータキューブを照会することによりレコードを要求することができる。幾つかの実施態様では、クエリは構造化照会言語クエリ（ＳＱＬクエリと呼ばれることがある）であり、データキューブには、処理のためにＳＱＬクエリを受信するインターフェース（例えば、ユーザインターフェース又はアプリケーションプログラミングインターフェース等の別の種類のインターフェース）を介してアクセスすることができる。ＳＱＬシンタックスを有するクエリについて、本明細書において後述する。読みやすさのために、「分かりやすい英語」クエリを使用する幾つかの例を提供する。典型的なクエリ処理実施態様は、これらの「分かりやすい英語」クエリを処理せず、正確にはＳＱＬ言語又は別の照会言語で定義されたクエリを使用する。

【0019】

クエリは、ユーザが各階層に望む詳細のレベルの仕様を含むことができる。例えば、クエリ「各州での性別ごとの購入数は？」は、場所階層１０６内の州レベル詳細及び性別階層１０２内の性別レベル詳細（利用可能な唯一の詳細レベル）を必要とする。そのようなクエリにより生成されるレコードは、州次元及び性別次元の値が入ったフィールドを含む。レコードは、クエリに関連する尺度が入ったフィールドも含む。尺度は、異なる次元詳細レベルで集計された値（通常、数値）である。この例では、データキューブは、データキューブがクエリに答えられるようにする購入数尺度を有する。その他の次元（例えば、市、郵便番号、及び顧客ステータス）のフィールドは空欄である。

【0020】

ＳＱＬクエリが使用されることが多いが、明確にするために、本明細書では分かりやすい英語のクエリを例として使用する。例えば、クエリ「各州での性別ごとの購入数は？」は、以下のレコードを返し得る。

【0021】

【表1】

【0022】

別の例では、クエリ「各市での男性による購入数は？」は、場所階層１０６内の市レベル詳細及び性別階層１０２内の性別レベル詳細を必要とする。そのようなクエリにより生成されるレコードは、州次元、市次元、及び性別次元の値が入ったフィールドを含む。クエリは以下のレコードを返し得る。

【0023】

【表2】

【0024】

このようにして、データキューブを照会して、データキューブに記憶されたデータの「スライス」、例えば、返されたデータの次元が、クエリにより指定されるように制約された記憶データの部分を取得することができる。データキューブは、データの多くの重複スライスを含むものとして考えることができる。図１Ｂ及び図１Ｃは、データキューブ内のデータ及びデータのサブセットが重複することができる様式を可視化したものを示す。

【0025】

図１Ｂは、データのスライス１０８（例えば、次元の１つ又は複数に特定の値を有するデータキューブのデータのサブセット）の例を示す。この例では、スライス１０８は、性別次元に「男性」の値を有するデータを含む。データは、州及び顧客ステータスにより分けられる。したがって、このスライス１０８内のデータは、州及び顧客ステータスにより分けられた全男性の尺度を要求するクエリに応答し得る。スライス１０８により表されるデータを作成するために、計算システムは、性別に「男性」の値を有するデータレコードの異なる値の州及び顧客ステータスに対応する尺度を予め計算したであろう。これは通常、他のスライスに対応する尺度が計算されたのと同時に行われる。例えば、「女性」及び「指定なし」の値を有するデータレコードについての他のスライスのデータが、予め計算されていたかもしれない。他の次元に特定の値を有するデータレコードについてのスライスも予め計算されたであろう。例えば、顧客ステータスに「非アクティブ」の値を有するデータレコードについてのスライスを予め計算することができ、そのようなデータレコードは州及び性別で分けることができる。

【0026】

データキューブはデータの尺度を含むことができるため、尺度の集計を予め計算することができ、それにより、クエリ内の特定の次元の詳細レベルを動的に変更することができ、それにより、クエリを受信したときに必要とされる処理時間量及び処理能力量を低減することができる。図１Ａを手短に参照すると、データキューブ１００内のデータは、場所次元で州レベル詳細に分けられて示されている。ユーザは、州レベルの代わりに市レベルの詳細でデータを取得したいことがある。したがって、図１Ｃに示されるように、システムは、データキューブ１００に記憶されたデータを市レベル詳細で素早く検索することができる。この例では、州次元に「ＣＡ」の値を有するデータの市レベル詳細１１０ａが示されている。データは次元の全ての組み合わせ及び次元詳細の全ての組み合わせについて予め計算されているため、システムはそのような処理を需要時に実行する必要がない。さらに、異なる照会をデータに対して実行して、システムに郵便番号レベル詳細１１０ｂでデータを検索させることができる。この例では、市次元に「ハリウッド」の値を有するデータについての郵便番号レベル詳細が示されている。この詳細レベルを使用して、市の代わりに、例えば郵便番号で分けられた尺度を取得することができる。

【0027】

本明細書に記載される技法を使用して実施されるデータキューブ１００は、ＩＣＦＦに記憶することができる。例えば、図１Ｄに示されるように、データキューブ１００のデータは、ＩＣＦＦ技法に従ってフォーマットされたデータを記憶するフラットファイル１２２ａ、１２２ｂ、１２２ｃの集まり１２０に記憶することができる。データには、本明細書に記載される技法を使用してアクセスすることができる。

【0028】

データはデータキューブにいかに記憶されるか
レコードは、クエリに応答して、照会アルゴリズムと呼ばれることがある照会技法に基づいて返される。しかし、照会アルゴリズムの詳細について考察する前に、照会アルゴリズムがいかに機能するかを理解する枠組みを提供するために、データがデータキューブにいかに記憶されるかについてまず説明する。

【0029】

上述したように、データキューブはＩＣＦＦに記憶することができる。図２を参照すると、レコード記憶・検索システム２００は、ソースＡ〜ソースＣ等の１つ又は複数のソースから、複数のデータファイル２０１等の１組のデータレコードを受信する。データは、データの個々にアクセス可能なレコードとして表現することができる情報を含む。データは、１つ又は複数の次元（例えば、データのカテゴリ又はデータの属性）を有するデータキューブの部分であることができる。例えば、各次元は、データレコードのフィールドに対応することができる。データレコードの少なくとも幾つかはそれぞれ、各次元に各データ値を含む。

【0030】

例では、データリポジトリは、物流データ又は商業データ、例えば、様々な小売り企業からの個々の取引を表すデータを１つ又は複数の通信ネットワークから受信し得る。取引の少なくとも幾つかは、次元のデータ値を含む。次元は、特に、顧客の顧客ステータス、性別、州、市、及び郵便番号を含み得る。レコード処理モジュール２０２は、取引に関連する値がレコードに記憶されるように、データが所定のレコードフォーマットに従ってフォーマットされることを保証する。幾つかの場合、これは、ソースからのデータをレコードフォーマットに変換することを含み得る。他の場合、１つ又は複数のソースは、レコードフォーマットに従って既にフォーマットされたデータを提供し得る。

【0031】

レコード処理モジュール２０２は、記憶されたレコードに素早くアクセスする必要があり得るか否か等の様々な要因に応じて、様々なタイプのデータ構造に記憶されるようにレコードを準備する。圧縮レコードファイルへの圧縮記憶に向けてレコードを準備する場合、処理モジュール２０２は、各レコードを識別する主キー値によりレコードをソートし、重複しない主キー値範囲に対応するレコードの組にレコードを分ける。例えば、レコードの各組は、所定数のレコード（例えば、１００のレコード）に対応し得る。

【0032】

ＩＣＦＦを管理する場合、ファイル管理モジュール２０４は、各組のレコードをデータの圧縮ブロックに圧縮する。これらの圧縮ブロックは、ＩＣＦＦのボリュームに記憶され、ＩＣＦＦのボリュームはレコード記憶装置２０６（例えば、１つ又は複数のハードディスクドライブ等の不揮発性記憶媒体）に記憶される。

【0033】

システム２００は、ＩＣＦＦ内の各ブロックにエントリを含むインデックスを提供するインデックス付与・サーチモジュール２０８も含む。より詳細に後述するように、インデックスを使用して、所与のレコードを含み得るブロックを見つける。インデックスは、インデックス記憶装置２１０内のインデックスファイルに記憶することができる。例えば、インデックスファイルは、圧縮レコードファイルと同じ記憶媒体に記憶することができ、一方、インデックスファイルは比較的高速のメモリ（例えば、ダイナミックランダムアクセスメモリ等の揮発性記憶媒体）に記憶することもでき、その理由は、インデックスファイルが通常、圧縮レコードファイルよりもはるかに小さいためである。

【0034】

インターフェースモジュール２１２は、エージェントＡ〜エージェントＤ等の人間及び／又はコンピュータエージェントに記憶レコードへのアクセスを提供する。例えば、インターフェースモジュール２１２は、クレジットカード顧客が取引を監視するオンラインアカウントシステムを実施することができる。様々な基準を満たす取引情報への要求は、システム２００により処理することができ、レコード記憶装置２０６に記憶された圧縮ブロック内から、対応するレコードを検索することができる。

【0035】

１つ又は複数のソースからの入力レコードのストリームは、処理されて圧縮レコードファイルを生成する前に一時的に記憶し得る。

【0036】

図３は、ＩＣＦＦ内のレコードを管理する例を示す。システム２００は、ＩＣＦＦのボリューム３００に記憶するレコード３０２を受信する。レコードは、より詳細に後述するように、レコード記憶装置２０６内の所与のレコードを一意に識別することができる主キーの値に従ってソートし得る。幾つかの例では、レコード３０２は１つ又は複数のフラットファイルに記憶される。

【0037】

図３に示される例では、レコード３０２は、主キー値：Ａ、ＡＢ、ＣＺ、ＤＤ等により識別される。この例では、簡明にするために、レコードは、比較的単純な（例えば、単純な文字列である）主キー値に従って英数字でソートされるが、本明細書での後の例での主キー値は、より複雑性が高い主キー値を有する。システム２００は、主キー値Ａ〜ＤＤを有する第１の組のＮ個のレコードを圧縮して、ブロック１と記された対応する圧縮ブロックを生成することができる。次の組のレコードは、主キー値ＤＸ〜ＧＦを有する、ソートされたレコードの次のＮ個を含むことができる。ファイル管理モジュール２０４は、任意の多種多様な可逆的データ圧縮アルゴリズム（例えば、レンペル−ジヴ型アルゴリズム）を使用することができる。連続した各圧縮ブロックを結合して、圧縮レコードファイル３０４（例えば、図１Ｄに示されるフラットファイル１２２ａ〜１２２ｃの１つ等のフラットファイル）を形成する。

【0038】

ＩＣＦＦボリューム３００はインデックスファイル３０６も含む。インデックス付与・サーチモジュール２０８は、インデックスファイル３０６内に、各圧縮ブロックのエントリ（例えば、ブロック１、ブロック２等）を生成する。インデックスエントリは、例えば、対応する１組の非圧縮レコード内の第１のレコードの主キーにより、各圧縮ブロックを識別する主キーフィールド３０８を含む。エントリは、圧縮レコードファイル３０４内の識別された圧縮ブロックの記憶ロケーションを識別するロケーションフィールド３１０も含む。例えば、ロケーションフィールドは、レコード記憶装置２０６内の絶対アドレスの形態又はレコード記憶装置２０６内の圧縮レコードファイル３０４の冒頭のアドレスからのオフセットの形態のポインタを含むことができる。圧縮レコードファイル３０４内で所与のレコードをサーチするために、モジュール２０８は、より詳細に後述するように、主キーフィールド３０８に基づいたインデックスファイル３０６のサーチを実行することができる。

【0039】

ＩＣＦＦは複数のボリューム（例えば、図３の複数のＩＣＦＦボリューム３００）を含むことができる。各ＩＣＦＦボリュームは、少なくとも１つの圧縮レコードファイル（例えば、フラットファイル）及びインデックスファイル（幾つかの例では、これもフラットファイルであり得る）を含む。例えば、初期圧縮レコードファイル３０４が生成された後に、システム２００がレコードを受信する場合、それ実施形態の圧縮レコードファイル及びインデックスファイルを含む新しいＩＣＦＦボリュームを作成することができる。幾つかの実施態様では、新しい圧縮レコードファイルを初期圧縮レコードファイル３０４に添付して、複合圧縮レコードファイルを形成することができ、新しいインデックスファイルを初期インデックスファイル３０６に添付して、複合インデックスファイルを形成することができる。任意の数の圧縮レコードファイルを添付して、複合圧縮レコードファイルを形成することができる。インデックス付与・サーチモジュール２０８が、複合圧縮レコードファイル内の所与の主キー値を有するレコードをサーチしている場合、モジュール２０８は、対応するインデックスファイルを使用して、添付された圧縮レコードファイルのそれぞれ内のレコードをサーチする。代替的には、所与のレコードを要求するエージェントは、サーチする複合圧縮レコードファイルを有する何らかの数の圧縮レコードファイル（例えば、最も新しく生成された１０個の圧縮レコードファイル又は１時間以内に生成された任意の圧縮レコードファイル）を指定することができる。

【0040】

なお図３を参照すると、データは、時間間隔（例えば、１日に１回、１時間に１回等）においてバッチでデータキューブにロードすることができる。データの各バッチは１つ又は複数のレコード３０２を含む。バッチがロードされると、バッチに実行ＩＤ（ＲｕｎＩＤ）が割り当てられ、実行ＩＤは、所与の時間にロードされた特定のバッチを識別する値である。バッチ内の全てのレコードには同じ実行ＩＤが割り当てられる。単一の時刻／日付けスタンプが各実行ＩＤに関連付けられる。幾つかの実施態様では、実行ＩＤは数値（例えば、整数値）である。

【0041】

各ロード動作に関連する情報は、これもまたＩＣＦＦで記憶されるロードカタログに記憶される。ロードカタログは、各ロード動作のレコードを含む。データのバッチがデータキューブにロードされる都度、特定のロード動作に対応するレコードが、ロードカタログ内で作成される。ロードカタログ内の各レコードは、ロード動作に関連付けられた実行ＩＤ、ロード動作の時刻／日付スタンプ、及びロードされたデータが常駐する特定のＩＣＦＦボリュームの識別子（例えば、ファイル名）を含む。他の方式もサポートされるが、ＩＣＦＦボリュームは通常、日付により分離される。レコードは、ロード動作に関する診断統計を含むことができる。データがいつロードされたかが厳密には未知である場合、ロードカタログを使用して、データを要求することができる。例えば、「最新」データを要求したいユーザは、ロードカタログにアクセスして、最新データが常駐する場所を特定することができる。

【0042】

幾つかの実施態様では、ロードされたデータ内のデータレコードは、ＩＣＦＦに書き込まれる前にソートし、及び／又はグループ化される。例えば、データレコードは、主キーに従ってソートし、及び／又はグループ化し得、データレコードは、ソートされ、及び／又はグループ化された形態でＩＣＦＦに記憶することができる。図４は、ＩＣＦＦで見られ得る、一例としてのデータレコード４００を示す。データレコード４００は、レコード識別子フィールド、実行ＩＤフィールド、詳細マスクフィールド、顧客ステータスフィールド、性別フィールド、州フィールド、市フィールド、郵便番号フィールド、及び主キーフィールドの値を含む。

【0043】

主キーは２つの固定フィールド−実行ＩＤ及び詳細マスク−を含み、その後に各次元のフィールドを含む。図１Ａ及び図４に関して上述した例を参照すると、データキューブの主キー仕様は、｛実行ＩＤ，詳細マスク，顧客ステータス，性別，州，市，郵便番号｝であり、データレコード４００の主キーは｛１，０ＡＣ，０，１０１，２０１，３０２，４０４｝である。したがって、ロードされたデータレコードは、詳細に後述するように、まず実行ＩＤにより、次に詳細マスクにより、次に顧客ステータスにより、次に性別により、次に州により、次に市により、そして最後に郵便番号によりソートされる。幾つかの実施態様では、ロードされたデータは適宜順序づけられ、したがって、ＩＣＦＦボリュームに書き込まれる前、ソートされる必要がない。例えば、元のデータは、ＩＣＦＦボリュームに書き込まれるように準備される前、適切な順序で生成されていることがある。

【0044】

実行ＩＤ−実行ＩＤには時刻／日付スタンプが関連付けられているため、レコードはまず、レコードがいつロードされたかに基づいて時系列的にソートされる。

【0045】

詳細マスク−一般に、詳細マスクは、所与のレコード内の階層の詳細レベルの表現である。幾つかの実施態様では、詳細マスクは、複数の詳細レベルについての情報を符号化する１つのスカラー値である。このようにして、詳細マスクは、ベクトル等のより複雑なデータ構造を使用しないように記憶することができる。幾つかの例では、詳細マスクは、各階層に１つの文字を有する固定長ストリングからなる。図１Ａに示される例を続けると、データキューブ例は３つの階層を有する：顧客ステータス（一次元）、性別（一次元）、及び場所（三次元−州、市、及び郵便番号）。詳細マスク内の最初の文字は、顧客ステータスの詳細レベルを指定し、２番目の文字は性別の詳細レベルを指定し、３番目の文字は場所の詳細レベルを指定する。所与の詳細レベルが０である場合、レコード内のその次元に詳細は存在しない。例えば、詳細マスク「０００」は、３つの階層のいずれの次元にも詳細が存在しないことを示す。

【0046】

本明細書に示される詳細マスク例では、大文字の英字は、他の全ての詳細レベルを示すのに使用される。文字Ａは、レベル１詳細が所与の次元に存在することを示す。例えば、詳細マスクＡ０Ｂは、顧客ステータスの詳細及び市（第２の）レベルまでの場所の詳細があることを示す。関連付けられたレコードにおいて、顧客ステータスフィールド、州フィールド、及び市フィールドが埋められ、他の全ての次元フィールドが空欄であることを予期する。幾つかの実施態様では、尺度フィールドは常に埋められる。別の例では、詳細マスク０ＡＣは、性別、州、市、及び郵便番号の詳細があることを示す。

【0047】

主キー仕様での次元フィールドの順序は、各フィールドの基数（例えば、フィールドに可能な値の数）に基づく。例えば、顧客ステータスは３つの可能な値を有する：「非アクティブ」、「アクティブ」、及び「好ましい」。性別も３つの可能な値を有する：「男性」、「女性」、及び「指定なし」。したがって、これらの２つの次元は、主キー仕様において最初に現れ、次に州（概ね５０の可能な値）、市（５０を超える可能な値）、そして郵便番号（市に可能な値の数よりも大きい）が続く。

【0048】

図５Ａ〜図５Ｃは、主キー仕様｛実行ＩＤ，詳細マスク，顧客ステータス，性別，州，市，郵便番号｝に従ってソートされたサンプルデータレコードのバッチを表す表５００の例を示す。この例では尺度フィールドは示されていないが、通常、尺度フィールドは、この種のテーブルの現実世界での実施態様に含められる。テーブル５００は、括弧内に関連するサロゲートＩＤ（例えば、数値コード）を有する自然値を示す。サロゲートＩＤは、ファイルに記憶されるデータ量を低減するために、ＩＣＦＦデータファイルで使用されるプレースホルダ値である。例えば、数値コードは、文字列よりも記憶する必要があるデータが少なく、したがって、文字列は一旦、別個のロケーションに記憶し、数値を相互参照することができる。幾つかの実施態様では、データキューブはサロゲートＩＤを記憶し、外部メカニズム（例えば、マッピングファイル）が、自然値とサロゲートＩＤとのマッピングを取り扱う。幾つかの実施態様では、サロゲートＩＤは、データレコードをソートするために、値の順序を決定する。

【0049】

レコードは、同じ実行ＩＤを有するデータレコードが一緒にグループ化されるように順序づけられる。幾つかの実施態様では、同じ実行ＩＤを有する全てのレコード（例えば、同じバッチの一部であるレコード）は、同じＩＣＦＦボリュームに記憶される。幾つかの実施態様では、特定のＩＣＦＦボリュームに記憶された全てのレコードは全て、同じ実行ＩＤを有する。このようにして、実行ＩＤは大方、レコードを様々なＩＣＦＦボリュームにグループ化する方法として使用される（例えば、実行ＩＤが特定のＩＣＦＦボリューム内のレコードのソートに使用されるのとは対照的に）。１つの時刻／日付スタンプが各実行ＩＤに関連付けられるため、幾つかの実施態様では、特定のＩＣＦＦボリューム内の全てのレコードには同じ時刻／日付スタンプを関連付けることができる。

【0050】

上述したソート技法は、レコードがロードされた時刻／日付に基づいて、特定のＩＣＦＦボリューム内の全てのレコードを時系列的にソートできるようにする。このようにして、レコードがロードされた時刻／日付範囲に基づくクエリが、クエリ結果を返すためにアクセスする必要があるＩＣＦＦボリューム数は最小である傾向を有し、それにより、読み出す必要があるブロック及び／又はボリュームの数を最小に抑える。

【0051】

各レコードグループは、詳細マスクに従ってサブセットにグループ化し得る。サブセットは、詳細マスク及びソート基準に従って構成することができる。幾つかの実施態様では、ソート基準は、小さい詳細マスク（例えば、提供される詳細度が低いことを示す低い英数字値を有する詳細マスク）を有するレコードを大きな詳細マスク（例えば、提供される詳細度が高いことを示す高い英数字値を有する詳細マスク）を有するレコードの前に並べさせる。

【0052】

各サブセット内のレコード（例えば、同じ詳細マスクを有するレコード）は、データレコードの様々な次元のデータ値に従って順序づけることができる。例えば、レコードは、第１の次元（例えば、顧客ステータス次元）のデータ値に従ってサブグループにグループ化し得る。次に、サブグループは、第１の次元のデータ値及びソート基準に従って構成される。幾つかの実施態様では、ソート基準は、次元の数値データ値が小さいレコードをその次元の数値データ値が大きいレコードの前（例えば、上）に並べさせる。

【0053】

上述したように、次元は、各次元の基数に基づいて主キー仕様において順序づけられる。したがって、顧客ステータス次元は、第２の次元（例えば、性別次元）で可能なデータ値数と同数又は少数の可能なデータ値数を有する。この例では、顧客ステータス次元及び性別次元はそれぞれ、３つの可能なデータ値を有する。

【0054】

各サブセット内のレコードがいかに順序づけられるかを説明するために、表５００の更に下に生じるレコードを示す図５Ｃを参照する。図５Ｃに示されるレコードは、レコードがいかに順序づけられるかを示すのに特に有用であり、その理由は、図５Ｃに示されるレコードが、データキューブのデータに可能な最高レベルの詳細マスクを有するレコードに関連するためである。特に、レコード＃２０８〜２３７は、詳細マスクフィールドの値「ＡＡＣ」を有し、これは、レコードが各次元にデータ値を含むことを示す。

【0055】

図５Ｃに示されるデータレコードは２つのサブグループにグループ化される：レコード＃２０８〜２３４を含む第１のサブグループ及びレコード＃２３５〜２３７を含む第２のサブグループ。第１のサブグループ内のレコードは、顧客ステータス次元にデータ値「１」を有し、第２のサブグループ内のレコードは、顧客ステータス次元にデータ値「２」を有する。２つのみのサブグループがここに示され説明されるが、追加のレコード及び追加のサブグループが存在する。例えば、顧客ステータス次元にデータ値「３」を有するレコードを含む第３のサブグループが存在する。

【0056】

サブグループは、顧客ステータス次元のデータ値に従って構成される。幾つかの実施態様では、サブグループは、顧客ステータス次元に小さい数値データ値を有するサブグループが、顧客ステータス次元に大きな数値データ値を有するサブグループの前に並べられるように順序づけられる。この例では、第１のサブグループは第２のサブグループの前に配置される。

【0057】

各サブグループのデータレコードは、各サブグループのデータレコードが性別次元の値によってソートされるように、性別次元のデータ値に従って配置される。例えば、レコード＃２０８〜２１６は性別次元にデータ値「１０１」を有し、レコード＃２１７〜２２５は性別次元にデータ値「１０２」を有し、レコード＃２２６〜２３４は性別次元にデータ値「１０３」を有する。幾つかの実施態様では、データレコードは、性別次元に小さい数値データ値を有する各サブグループのデータレコードが、性別次元に大きな数値データ値を有する各サブグループのデータレコードの前に並べられるように順序づけられる。この例では、レコード＃２０８〜２１６はレコード＃２１７〜２２５の前に並べられ、レコード＃２１７〜２２５はレコード＃２２６〜２３４の前に並べられる。

【0058】

データレコードは、上述した様式と同様に残りの次元のデータ値に従って更に順序づけ／ソートされる。例えば、レコード＃２０８〜２１６、レコード＃２１７〜２２５、及びレコード＃２２６〜２３４はそれぞれ、データレコードのサブ−サブグループ（例えば、サブグループのサブセット又は「二次」サブグループ）を表すことができ、各サブ−サブグループのデータレコードは、続く次元のデータ値に従って配置することができる。レコード＃２０８〜２１６を含む第１のサブ−サブグループを例としてとると、レコードは、州次元のデータ値に従って配置され、データレコードの２つのサブ−サブ−サブグループを作成する。データレコードのこれらのサブ−サブ−サブグループのそれぞれは、市次元のデータ値に従って更に配置され、その結果生成されるサブセット（例えば、サブ−サブ−サブ−サブグループ）内のレコードは、郵便番号次元のデータ値に従って更に配置することができる。その他のサブグループ（及びサブ−サブグループ及びサブ−サブ−サブグループ）のレコードも同様に、この階層様式で順序づけられる。

【0059】

図６はセンサス６００の例を示す。更に詳細に後述するように、センサスを使用して、階層内の一次元に対して制約を有するクエリを、その階層内に追加の制約を追加することにより変更することができる。

【0060】

データのバッチがＩＣＦＦにロードされる都度、関連データをセンサスに記憶することができる。センサスもＩＣＦＦに記憶される。幾つかの実施態様では、センサスは、データキューブのデータを含むファイルとは別個のＩＣＦＦボリュームに記憶される。センサスは、レベルが１よりも大きい階層に次元の関連値を記憶する。この例では、場所階層は、州次元（レベル１）、市次元（レベル２）、及び郵便番号次元（レベル３）を含む。したがって、センサスは、市次元値及び郵便番号次元値の関連値を記憶する。

【0061】

クエリが市次元に対する制約を含む場合、センサス６００を使用して、州次元の対応する値を決定することができる。同様に、レコードが郵便番号次元に対する制約を含む場合、センサス６００を使用して、市次元及び州次元の対応する値を決定することができる。対応する値は、追加の制約としてクエリに追加することができる。例えば、クエリは、「ボストンにおける顧客について、性別で分けられた購入数は？」を要求し得る。この例では、レコード記憶・検索システム２００は、レコードが市次元フィールドに値「ボストン」（又は例えば、「ボストン」に対応するサロゲートＩＤ（３０３））を有する場合、州次元フィールドが値「マサチューセッツ」（又は例えば、「マサチューセッツ」に対応するサロゲートＩＤ（２０２））を有するべきであることを述べるセンサス６００にアクセスすることができる。システム２００は、例えば、「マサチューセッツ州ボストンにおける顧客について、性別で分けられた購入数は？」という追加の制約を含むようにクエリを変更し得る。同様に、センサスは、クエリが郵便番号次元フィールドに対して特定の制約を有する場合、市次元フィールド及び州次元フィールドが、郵便番号に対応する市及び州に対応する値を有するべきであることを述べる。このようにして、よりロバストな照会を可能にする追加情報でクエリを補足することができる。そのような情報は、より詳細に後述するように、反復最適化法に従ってクエリが処理される場合、特に有用であることができる。

【0062】

データキューブの照会
データキューブを照会して、データキューブに記憶されたレコードを返すことができる。クエリは、入力としてＳＱＬクエリを使用する照会アルゴリズムに基づく。例えば、入力クエリは以下であり得る。

【数1】

【0063】

このクエリは、「最近３ヶ月中、マサチューセッツ州の市での性別で分けられた購入数は？」として「分かりやすい英語」で表現することができる。

【0064】

クエリは照会アルゴリズムにより処理されて、「キューブ」と呼ばれるデータキューブを照会する。照会アルゴリズムの例は以下である。

【数2】

【0065】

クエリはまず、解析される。解析は、時刻／日付境界（もしあれば）を識別することと、次元制約を識別することとを含む。クエリが解析されるとき、８／１／２０１５〜１１／１／２０１５の範囲内で作成されたレコードのみが結果セットに含まれるべきであることを示す時刻／日付境界８／１／２０１５〜１１／１／２０１５が識別される。次元制約Ｓｔａｔｅ＝‘ＭＡ’も識別される。

【0066】

幾つかの実施態様では、解析は、クエリが反復最適化の候補であるか否かを判断することも含むが、これについてはより詳細に後述する。

【0067】

次に、結果セットへの包含に考慮されるレコードが出力詳細マスクを含むように、入力パラメータの評価に基づいて、詳細レベルを含む出力詳細マスクが計算される。上述したように、詳細マスクは、各階層−顧客ステータス、性別、及び場所−の詳細レベルを指定する。クエリ「最近３ヶ月中、マサチューセッツ州での性別で分けられた購入数は？」は、いかなる顧客ステータス情報も必要としないため、顧客ステータスの詳細レベルは０である。クエリは性別情報を必要とするため、性別階層の詳細レベルは１である（例えば、性別階層に利用可能な詳細な最高レベル）。クエリは場所情報も必要とする−特に、クエリは州情報及び市情報を必要とする。したがって、場所階層の詳細レベルは２である。郵便番号情報はこのクエリに関連しないため、場所詳細レベル３は必要ない（例えば、仮に場所詳細レベル３がクエリの処理に使用されるならば、現目的ではシステムリソースを無駄にすることになる）。したがって、このクエリの出力詳細マスクは０ＡＢである。

【0068】

詳細マスクは、レコードのソートに使用される主キーにおいて比較的早期に作成される（例えば、実行ＩＤに次いで２番目）ため、照会アルゴリズムは、ＩＣＦＦデータファイル内のこの特定の範囲の連続レコードにフォーカスを素早く狭めることができる。例えば、図５Ａ〜図５Ｃを手短に参照すると、詳細マスク０ＡＢを有する全てのレコード（例えば、レコード＃２０〜２７）は一緒にグループ化される。しかし、図５Ａ〜図５Ｃに示されるレコードの全てが同じ実行ＩＤ（及び例えば、同じ時刻／日付スタンプ）に対応することに留意されたい。クエリの時間枠内に入る日付／時刻に対応する他の実行ＩＤも存在し得、それらの実行ＩＤを含むレコードも解析する必要があり得る。

【0069】

出力詳細マスクが計算されると、レコード記憶・検索システム２００は、クエリを満たすために必要な実行ＩＤのリストを取得する。すなわち、システム２００は、クエリにより指定された時間枠（例えば、４／４／１５の１：００ＰＭ〜７／４／１５の１：００ＰＭ）中に生じる日付／時刻に対応する実行ＩＤを識別する。上述したように、データのバッチがデータキューブにロードされる都度、特定のロード動作に対応するレコードがロードカタログ内に作成される。ロードカタログ内の各レコードは、ロード動作に関連する実行ＩＤ、ロード動作の時刻／日付スタンプ、及びロードされたデータが常駐する特定のＩＣＦＦボリュームの識別子（例えば、ファイル名）を含む。したがって、システム２００は、ロードカタログにアクセスして、どのＩＣＦＦボリュームが、クエリを満たすタイムスタンプを有するデータを含むかを識別することができる。さらに、実行ＩＤは、レコードのソートに使用される主キーの最初の要素であるため、照会アルゴリズムは、ＩＣＦＦデータファイル内（例えば、ＩＣＦＦデータファイルの複数のボリュームにわたってさえも）の特定の範囲の連続レコードにフォーカスを素早く狭めることができる。

【0070】

データキューブにロードされるデータの各バッチは、異なるファイル（例えば、異なるＩＣＦＦボリューム）に常駐し得るため、クエリはバッチ（例えば、実行ＩＤ）ごとに別個に実行される。以下の反復プロセスは、１つ又は複数の識別された実行ＩＤのそれぞれに対して実行される。

【0071】

ロードカタログを使用して識別されたＩＣＦＦボリュームファイル名を使用して、特定の実行ＩＤに対応するＩＣＦＦボリュームが開かれる。

【0072】

クエリは、更に詳細に後述するように、クエリに関連する１組の正規化された（例えば、外積として）制約にわたり繰り返し実行される。この例では、唯一の次元制約はＳｔａｔｅ＝［ＭＡ］である。換言すれば、結果は、州次元に値ＭＡを有するレコードのみを含むべきであり、その他の次元の特定の値は、レコードがクエリを満たすか否かを判断する目的に無関係である。時間枠制約もあるが、これは、実行ＩＤのリストを識別し、続けて、ロードカタログを使用して識別されたＩＣＦＦボリュームファイル名を識別することにより既に考慮されている。

【0073】

Ｓｔａｔｅ＝［ＭＡ］はこのクエリで唯一の次元制約であるため、クエリの反復は１回のみでよい。しかし、代わりにクエリが「最近３ヶ月中、マサチューセッツ州、コネチカット州、又はニューヨーク州の市での男性による購入数は？」であったと考える。そのような例では、次元制約はＳｔａｔｅ＝［ＭＡ，ＣＴ，ＮＹ］；Ｇｅｎｄｅｒ＝［Ｍａｌｅ］である。このクエリを満たすために、全ての制約の外積を実行することができる。制約の外積は、サブクエリの複数の反復を使用して実行されるクエリの結果である。例えば、クエリの最初の反復は、制約Ｓｔａｔｅ＝［ＭＡ］及びＧｅｎｄｅｒ＝［Ｍａｌｅ］を含み、クエリの２回目の反復は制約Ｓｔａｔｅ＝［ＣＴ］及びＧｅｎｄｅｒ＝［Ｍａｌｅ］を含み、クエリの３回目の反復は制約Ｓｔａｔｅ＝［ＮＹ］及びＧｅｎｄｅｒ＝［Ｍａｌｅ］を含む。全ての制約の外積は、１組の正規化された制約と呼ばれる。

【0074】

クエリの形態及びクエリが処理される方法は、クエリが反復最適化の候補であるか否かに依存する。反復最適化について以下に詳述し、実際、元の例でのクエリ（「最近３ヶ月中、マサチューセッツ州での性別で分けられた購入数は？」）は、反復最適化の候補であるが、ここでは、標準方法に従ってこのクエリを処理することについて説明する。

【0075】

標準方法
コンピュータ出力の詳細マスク及び制約を使用して、ｌｏｏｋｕｐ＿ｒａｎｇｅステートメントが計算される。ｌｏｏｋｕｐ＿ｒａｎｇｅは以下の入力パラメータをとる関数である：ｌｏｏｋｕｐ＿ｉｄ、１組の最小主キー値、及び１組の最大主キー値。ｌｏｏｋｕｐ＿ｉｄはルックアップリソース（例えば、特定のＩＣＦＦボリューム）への参照である。最小及び最大主キー値は、主キー仕様において定義されるフィールド内の値を指す。この例では、主キー仕様は｛実行ＩＤ，細部マスク，顧客ステータス，性別，州，市，郵便番号｝である。各フィールドに１つの最小値及び１つの最大値が指定される。ｌｏｏｋｕｐ＿ｒａｎｇｅ関数は、主キーが、指定される最小主キー値以上であるＩＣＦＦボリューム内の最初のレコード及び主キーが、指定される最大主キー値以下であるＩＣＦＦボリューム内の最後のレコードである１組のレコードを返す。

【0076】

データは各実行ＩＤで別個に収集されるため（例えば、反復プロセスの一環として）、実行ＩＤの最小値及び最大値は同一である。例えば、実行ＩＤの最小値及び最大値は、最初の反復の場合、「１」である。また、単一のクエリが単一の詳細マスクを指定するため、詳細マスクの最小値及び最大値も同一である（例えば、「０ＡＢ」）。

【0077】

各次元で、最小値及び最大値は以下のアルゴリズムに従って決定される。

【数3】

【0078】

クエリ「最近３ヶ月中、マサチューセッツ州での性別で分けられた購入数は？」は、１つのみの次元制約を必要とする：Ｓｔａｔｅ＝［ＭＡ］。したがって、州次元の最小値及び最大値は同一であり、値「２０２」を有し、これは、ＭＡに対応するサロゲートＩＤである（図５Ａ〜図５Ｃを参照して上述したように）。

【0079】

Ｓｔａｔｅ＝［ＭＡ］は唯一の次元制約であるが、クエリは、性別次元及び市次元の詳細を必要とする。したがって、最小値及び最大値は、性別次元及び市次元の両方でそれぞれ「０」及び「９９９９９９９９９」である。

【0080】

クエリは、顧客ステータス次元及び郵便番号次元の詳細を必要としない。したがって、顧客ステータス次元及び郵便番号次元の最小値及び最大値は「０」である。

【0081】

計算されたｌｏｏｋｕｐ＿ｒａｎｇｅステートメントは以下である。

【数4】

【0082】

実行されると、このｌｏｏｋｕｐ＿ｒａｎｇｅステートメントは、主キーが、指定された最小主キー値以上の最初のレコード及び主キーが、指定された最大主キー値以下である最後のレコードを見つける。最初のレコード、最後のレコード、及び全ての中間レコードは、クエリを満たし、結果セットに包含される。

【0083】

図５Ａ〜図５Ｃに示されるサンプルデータを参照すると、ｌｏｏｋｕｐ＿ｒａｎｇｅ関数へのこの呼び出しは、最初のレコードとしてレコード＃２２を返し、最後のレコードとしてレコード＃２５を返す。レコード＃２２〜２５は、ｌｏｏｋｕｐ＿ｒａｎｇｅ関数により返されるレコードセットに包含される。しかし、レコード＃２３及びレコード＃２４は、制約Ｓｔａｔｅ＝［ＭＡ］を満たさないため、クエリを満たさない。したがって、クエリを満たさないこれらの２つの余分なレコードをフェッチするデータ処理オーバーヘッドが無駄になる。これらのレコードは、結果セットが返される前に結果セットからフィルタリングして除去することができるが、フィルタリングも追加のデータ処理オーバーヘッドを必要とする。この例では、これらの２つの余分なレコードのフェッチに関わる追加のオーバーヘッドはほんの僅かであるが、規模がより大きな例では、多くの不必要なレコードのフェッチは、システム性能に有意な負の影響を及ぼし得る。不必要なデータ処理オーバーヘッドを避けるために、反復最適化法に従って幾つかの適格クエリを処理することができる。上述したように、この例で提示されるクエリ「最近３ヶ月中、マサチューセッツ州での性別で分けられた購入数は？」は、反復最適化に適格である。

【0084】

反復最適化法
レコード記憶・検索システム２００は、クエリが解析されるとき、クエリが反復最適化に適格であるか否かを判断する。クエリは、主キーにおける位置が、制約を受ける次元の左側にある（例えば、制約を受ける次元よりも低い基数を有する）制約を受けない次元の詳細を必要とする場合、反復最適化の候補である。前の例からのクエリ「最近３ヶ月中、マサチューセッツ州での性別で分けられた購入数は？」は、性別次元、州次元、及び市次元の詳細を必要とする。これらの３つの次元の中で、州次元のみが制約を受ける（例えば、Ｓｔａｔｅ＝［ＭＡ］）。性別次元及び市次元は制約を受けない。クエリは、顧客ステータス次元の詳細も郵便番号次元の詳細も必要としない。したがって、詳細マスクは「０ＡＢ」である。

【0085】

クエリは、ｉ）クエリが、制約を受けない次元である性別次元の詳細を必要とし、ｉｉｉ）性別次元（「Ａ」で表される）が、主キーにおいて場所階層の州次元（「Ｂ」で表される）の左側にあるため、反復最適化に適格である。

【0086】

反復最適化法は、全ての制約を満たすレコードのみをフェッチし、それにより、過剰フェッチを最小にするように複数のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しを策定することを含む。例えば、ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しは、性別次元の別個の各値−女性（１０１）、男性（１０２）、及び指定なし（１０３）について策定し処理することができる。ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しは以下のようになる。

【数5】

【0087】

各ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しの結果は、結果セットが、いかなる中間の非一致レコードも有さずに、クエリで必要とされるレコードのみを含むように連結される。

【0088】

性別次元の可能な各値は既知であるため、それぞれが３つの可能な値の１つを有する３つのｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しを容易に作成することが可能である。しかし、幾つかの例では、次元に別個の値の全てがシステムにとって未知であることがある。

【0089】

幾つかの実施態様では、特定の次元の別個の値は全て、ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しを策定し処理することにより取得することができる。例えば、図５Ａ〜図５Ｃを再び参照すると、レコード＃１２〜１４は、性別次元に３つの別個の値を含む。以下のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しは、性別次元に別個の値を含む全てのレコード（例えば、レコード＃１２〜１４）を返す。

【数6】

【0090】

システムは、変数ｉｔｅｒａｔｉｏｎ＿ｒｅｃｏｒｄ．Ｇｅｎｄｅｒを呼び出して、「ｉｔｅｒａｔｉｏｎ＿ｒｅｃｏｒｄ」レコードから「性別」フィールドの値を検索することにより、返されたレコードのそれぞれから性別次元の別個の各値を決定することができる。

【0091】

以下の簡易化されたアルゴリズムは、上記提供されたｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出し（例えば、性別次元の別個の値を全て決定する）及びｗｈｉｌｅループの一部である第２のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しを含む。第２のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しは、各反復で性別次元の別個の値の１つを受信し、クエリを満たす１組の結果を決定する。ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しの各反復の結果は、完全な結果セットが、いかなる中間の非一致レコードも有さずに、クエリで必要とされるレコードのみを含むように連結される。このようにして、第２のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しは、性別次元の様々な別個の値（例えば、システムにとって未知であり得る）への参照をサポートしながら、上記提供された３つの別個のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しと同様に実行される。簡易化されたアルゴリズムは以下である。

【数7】

【0092】

幾つかの実施態様では、更なる反復最適化が可能である。例えば、クエリが、主キーにおいて制約を受ける次元の左側にある複数の非制約次元の詳細を必要とする場合、追加の最適化を適用し得る。クエリ「性別で編成されたボストン在住の顧客のレコードを表示」を考える。前の例のクエリのように、このクエリも性別次元、州次元、及び市次元の詳細を必要とする。しかし、この例では、市次元が制約され（例えば、Ｃｉｔｙ＝［Ｂｏｓｔｏｎ］）性別次元及び州次元は制約されない。クエリは、顧客ステータス次元の詳細も郵便番号次元の詳細も必要としない。したがって、詳細マスクは「０ＡＢ」である。

【0093】

非制約次元（例えば、州次元）及び制約次元（例えば、市次元）のうちの一方は両方とも場所階層に属するので、クエリが反復最適化に適格であるか否かを判断するために、詳細マスク内の階層の位置を使用することができない。代わりに、これらの２つの次元の詳細レベルを使用して、非制約次元が制約時間の左側にあるか否かを判断する。低い詳細レベルを有する次元は、高い詳細レベルを有する次元の左にある。したがって、この例では、州次元は市次元の左側にある。

【0094】

クエリは、ｉ）クエリが複数の非制約次元−性別次元及び州次元−の詳細を必要とし、ｉｉ）性別次元が性別階層に属し、州次元が場所階層に属し、ｉｉｉ）性別階層（「Ａ」で表される）が場所階層（「Ｂ」で表される）の左側にあり、ｉｖ）州次元の詳細レベル（例えば、レベル１）が市次元の詳細レベル（例えば、レベル２）よりも低く、ｖ）市次元が制約次元であるため、更なる反復最適化に適格である。

【0095】

完全な結果セットを返すために、アルゴリズムは、性別及び州に可能な別個の値の全てを決定する必要がある。これは、第１のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出し（例えば、反復ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しと呼ばれることもある「外側の」ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出し）により行われる。次に、アルゴリズムは、別個の値の可能な各対にわたり反復して、クエリを満たす完全な結果セット（例えば、市次元に値「３０２」をそれぞれ有する１組のレコード、ここで、「３０２」はボストンに対応するサロゲートＩＤである）を返す。これは、第２のｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出し（例えば、出力ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出しと呼ばれることもある「内側の」ｌｏｏｋｕｐ＿ｒａｎｇｅ呼び出し）により行われる。この例のアルゴリズムは以下である。

【数8】

【0096】

このアルゴリズムは、性別及び州の全ての組み合わせにわたり反復し、各反復で内側のｌｏｏｋｕｐ＿ｒａｎｇｅを実行する。合計で９回の反復が実行され、その理由は、州次元に３つの別個の値があり（ＣＡ、ＭＡ、ＮＹ）、性別次元に３つの別個の値がある（女性、男性、指定なし）ためである。しかし、制約で指定される市（ボストン（３０３））は１つの州：ＭＡ（２０２）でのみ生じるため、これらの反復のうちの３つのみが実際に、クエリを満たすレコードを返す。仮にこの情報が事前にシステムで利用可能であったならば、Ｓｔａｔｅ＝［２０２］の制約を追加し、外側のｌｏｏｋｕｐ＿ｒａｎｇｅ関数から州次元をなくすことにより、他の６回の反復を回避することができ、それにより、呼び出し回数を内側のｌｏｏｋｕｐ＿ｒａｎｇｅ関数に低減することができた。そのようなアルゴリズムは以下である。

【数9】

【0097】

この更に最適化されたクエリを形成するために、システムは、ボストン（３０３）がＭＡ（２０２）でのみ生じることをシステムに教える関係情報にアクセスしなければならない。上述したように、そのような関係データはセンサスに記憶される。図６を手短に参照すると、センサス６００は、市次元がボストン（３０３）の値を有する場合、州次元はＭＡ（２０２）の値を有するべきであることを指定するエントリを含む。システムは、アルゴリズムを策定するとき、センサス６００にアクセスして、市次元値３０３に州次元値２０２が常に付随することを特定することができる。次に、システムは、それに従って更に最適化されるようにアルゴリズムを変更することができる。この技法は、「ハイドレート（hydrating）」（又は「推測」）制約、又はより詳細に、同じ階層内のより高レベルの次元へのハイドレート制約と呼ばれることがある。

【0098】

制約は、階層内の関連次元の深さに関係なくハイドレートすることができる。例えば、図５Ａ〜図５Ｃ及び図６を手短に参照すると、仮にクエリが「性別で編成された郵便番号９４６０９を有する顧客のレコードを表示」であったならば、市次元の制約（バークリー（３０１）及び州次元の制約（ＣＡ（２０１））がハイドレートされる。システムは、センサス６００を見て、この関連情報を特定する。

【0099】

クエリは、複数の非制約次元を含む場合にも最適化することができる。例はクエリ「郵便番号及び性別で編成された、マサチューセッツ州ボストン在住の顧客のレコードを表示」である。ここで、市次元及び州次元は制約され、郵便番号次元及び性別次元は、詳細を必要とし、制約されない。したがって、詳細マスクは「０ＡＣ」である。

【0100】

非制約次元（例えば、郵便番号次元及び性別次元）は同じ階層に属さないため、詳細マスクでの階層の位置を使用して、クエリが反復最適化に適格であるか否かを判断することができる。低い詳細レベルを有する次元は、高い詳細レベルを有する次元の左側にある。したがって、この例では、性別次元は郵便番号次元（例えば、場所階層の次元）の左側にある。

【0101】

クエリは、ｉ）クエリが複数の非制約次元−性別次元及び郵便番号次元−の詳細を必要とし、ｉｉ）性別次元が性別階層に属し、郵便番号次元が場所階層に属し、ｉｉｉ）性別階層（「Ａ」で表される）が場所階層（「Ｃ」で表される）の左側にあるため、更なる反復最適化に適格である。

【0102】

完全な結果セットを返すために、前の例おいて説明したものと同様のアルゴリズムを使用することができ、例えば、アルゴリズムは、性別及び郵便番号に可能な別個の値を全て特定する必要がある。例えば、性別及び郵便番号の全ての値を照会し、外積を実行する代わりに、例えば、別の技法は、性別次元及び郵便番号次元を含み、クエリに該当しない結果を除去した詳細マスクを使用するというものである。

【0103】

システムは、１つ又は複数の事前処理動作をデータキューブにロードされたデータに対して実行して、照会プロセスの効率を改善し得る。例えば、データの様々な集計をデータ準備及び／又はデータロードプロセスの一環として予め計算することができる（例えば、データがデータキューブにロードされる際又はロードされる前）。集計は、次元詳細の様々な組み合わせ又は多くの場合、次元詳細のあらゆる組み合わせに従って予め計算することができる。

【0104】

上述したように、特定のクエリに生成されたデータレコードは、クエリに関連する尺度が入れられたフィールドを含むことができる。尺度は、次元詳細の異なるレベルで集計された値である。例えば、クエリ「２０１４年の州ごとの購入数は？」は、購入数尺度を有するレコードを返す。クエリは以下のレコードを返し得る。

【0105】

【表3】

【0106】

別の例では、クエリ「２０１４年の市ごとの購入数は？」は以下のレコードを返し得る。

【0107】

【表4】

【0108】

更に別の例では、クエリ「２０１４年の性別ごとの各市での購入数は？」は、以下のレコードを返し得る。

【0109】

【表5】

【0110】

クエリの受信前、システムは、クエリを満たす結果を生成するために必要となる詳細のレベルを知らない。したがって、システムは、次元詳細の全ての組み合わせに従って様々な尺度の集計を予め計算することができる。例えば、システムは、少数の例を挙げれば、州で分けられた全ての男性、州で分けられた全ての女性、州で分けられた、アクティブな顧客である全ての男性、郵便番号で分けられた非アクティブな顧客である全ての女性、性別で分けられた非アクティブな全ての顧客、及び顧客ステータスで分けられた全ての州の購入数尺度を予め計算することができる。集計は予め計算されるため、クエリ受信時にクエリに答えるために必要とされる時間及び処理能力は有意に最小化することができる。

【0111】

上記例では、ＩＣＦＦに記憶されたデータキューブを説明したが、データキューブは他のタイプのファイルに記憶することもできる。例えば、データキューブは、構造化関係を有するレコードを含むファイル（例えば、リレーショナルデータベースに記憶されたファイル）に記憶することができる。しかし、本明細書に記載される特徴の多くは、ＩＣＦＦの状況に特によく適する。データは、ＩＣＦＦに書き込まれた後変更されないため、データは、ロック技法を使用せずにＩＣＦＦから読み出すことができる。したがって、データは、本発明を用いない場合には時間及び処理能力がかかるロックの設定なしで、又は本明細書を用いない場合には待ち時間を増大させるロックの解放を待つことなく、ＩＣＦＦに読み書きすることができる。データは、ＩＣＦＦに書き込まれた後変更されないため、古いデータにより使用されているリソース（例えば、記憶空間）が他の目的で必要な場合、古いデータを容易に識別し破棄することができる。ＩＣＦＦ内のデータはデータファイルから直接読み出すことができるため、ＩＣＦＦ内のデータは潜在的に、リレーショナルデータベース管理システム等の中間システムにより読み出しコマンドを実行する必要がある技法よりも素早く読み出すことができる。ＩＣＦＦ内のデータは通常、圧縮されるため、データは、他の技法を使用して記憶されるデータよりも使用する記憶空間を少なくし得る。

【0112】

上述した記憶／グループ化技法は、特定のＩＣＦＦボリューム内の全てのレコードが、レコードがロードされた時刻／日付に基づいて時系列的にソートされることを保証し、ｌｏｏｋｕｐ＿ｒａｎｇｅ関数を照会に特に有用なツールにする。このようにして、レコードがロードされた時刻／日付範囲に基づくクエリは、クエリ結果を返すために、最小数のＩＣＦＦボリュームにアクセスするだけでよい可能性が高く、それにより、読み出す必要があるブロック及び／又はボリュームの数を最小に抑える。

【0113】

主キー仕様は、ＩＣＦＦと上手く機能するように特に設計される。主キーは、比較的広く、多くのフィールドを含み、３つの主要セクションを有する：ｉ）実行ＩＤ、ｉｉ）詳細マスク、及びｉｉｉ）低い基数から高い基数に並べられた次元属性。実行ＩＤは日付のプロキシであるため、レコードは主に時系列的にソートされる。大半のクエリは特定の時刻／日時範囲を含むため、主キーは、入力／出力動作の数を最小に抑えながら、時系列データについてＩＣＦＦを照会するのに適する。

【0114】

データ処理システム
図７は、本明細書に記載されるシステム及び技法を使用することができるデータ処理システム７００の例を示す。システム７００はデータソース７０２を含み、データソース７０２は、それぞれが任意の種々のフォーマット（例えば、ＩＣＦＦ、データベーステーブル、スプレッドシートファイル、フラットテキストファイル、又はメインフレームにより使用されるネイティブフォーマット）でデータを記憶又は提供し得る、記憶装置又はオンラインデータストリームへの接続等の１つ又は複数のデータソースを含み得る。実行環境７０４は、事前処理モジュール７０６及び実行モジュール７１２を含む。実行環境７０４は、例えば、あるバージョンのＵＮＩＸオペレーティングシステム等の適するオペレーティングシステムの制御下で、１つ又は複数の汎用コンピュータ上でホストし得る。例えば、実行環境７０４は、ローカルに（例えば、対称型マルチプロセッシング（ＳＭＰ）コンピュータ等のマルチプロセッサシステム）若しくはローカルに分散した（例えば、クラスタとして結合される複数のプロセッサ若しくは超並列処理（ＭＰＰ）システム）、又はリモートに若しくはリモートに分散した（例えば、ローカルエリアネットワーク（ＬＡＮ）及び／又は広域ネットワーク（ＷＡＮ）を介して結合される複数のプロセッサ）、又はそれらの任意の組み合わせでの複数の中央演算処理装置（ＣＰＵ）又はプロセッサコアを使用するコンピュータシステムの構成を含むマルチノード並列計算環境を含むことができる。

【0115】

事前処理モジュール７０６は、データをデータソース７０２から読み出し、予め計算された集計（例えば、尺度）に関係する情報を記憶する。データソース７０２を提供する記憶装置は、実行環境７０４にローカル、例えば、実行環境７０４をホストするコンピュータに接続される記憶媒体（例えば、ハードドライブ７０８）に記憶されてもよく、又は実行環境７０４にリモート、例えば、リモート接続（例えば、クラウド計算基盤により提供される）を介して実行環境７０４をホストするコンピュータと通信するリモートシステム（例えば、メインフレーム７１０）でホストされてもよい。

【0116】

実行モジュール７１２は、事前処理モジュール７０６により生成された事前計算情報を使用して、クエリを処理する。出力データは、データソース７０２に記憶してもよく（７１４）、又は実行環境７０４にアクセス可能なデータ記憶システム７１６に記憶してもよく、又は他の方法で使用されてもよい。データ記憶システム７１６には、開発者７２０がクエリを提供可能な開発環境７１８によってもアクセス可能である。開発環境７１８は、幾つかの実施態様では、頂点間の有向リンク（作業要素、すなわち、データの流れを表す）により結ばれた頂点（データ処理構成要素又はデータセットを表す）を含むデータフローグラフとしてアプリケーションを開発するシステムである。例えば、そのような環境は、参照により本明細書に援用される「Managing Parameters for Graph-Based Applications」という名称の米国特許出願公開第２００７／００１１６６８号により詳細に記載されている。そのようなグラフベースの計算を実行するシステムは、参照により本明細書に援用される「EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS」という名称の米国特許第５，９６６，０７２号に記載されている。このシステムにより作成されるデータフローグラフは、グラフ構成要素により表される個々のプロセスに情報を入れ及び個々のプロセスから情報を出し、プロセス間で情報を移し、プロセスの実行順序を定義する方法を提供する。このシステムは、任意の利用可能な方法からプロセス間通信方法を選ぶアルゴリズムを含む（例えば、グラフのリンクによる通信パスは、ＴＣＰ／ＩＰ若しくはＵＮＩＸドメインソケットを使用してもよく、又は共有メモリを使用して、プロセス間でデータを渡してもよい）。

【0117】

事前処理モジュール７０６は、異なる形態のデータベースシステムを含め、データソース７０２を実施し得る種々のタイプのシステムからデータを受信することができる。データは、恐らくはヌル値を含め、各フィールド（「次元」、「属性」、又は「カラム」とも呼ばれる）に値を有するレコードとして編成し得る。データソースからデータを最初に読み出すとき、事前処理モジュール７０６は通常、そのデータソース内のレコードについての何らかの初期フォーマット情報から開始する。幾つかの状況では、データソースのレコード構造は、最初は既知ではないことがあり、その代わり、データソース又はデータの解析後に特定されることがある。レコードについての初期情報は、例えば、別個の値を表すビット数、レコード内のフィールドの順序、及びビットで表される値のタイプ（例えば、文字列、符号付き／符号なし整数）を含むことができる。

【0118】

幾つかの例では、データ処理システム７００は、クエリに基づいて、データフローグラフ等のコンピュータプログラムを生成し、そのコンピュータプログラムを実行することにより、クエリ（例えば、図１Ａに示されるデータキューブ１００等のデータキューブからデータを検索するのに使用されるクエリ）を処理することができる。そのような技法は、「Managing Data Queries」という名称の米国特許出願公開第２０１１／０１７９０１４Ａ１号、これもまた「Managing Data Queries」という名称の米国特許出願公開第２０１２／０２８４２５５Ａ１号、及び「Querying a Data Source on a Network」という名称の米国特許出願第１４／７５２，０９４号に記載されており、これらは全て参照により本明細書に援用される。

【0119】

データの記憶及び検索の手順
図８は、リレーショナルデータベース以外の記憶装置、例えば、１つ又は複数のフラットファイルにデータキューブのデータを記憶する手順８００を表すフローチャートを示す。手順８００は、例えば、図２に示されるレコード記憶・検索システム２００の構成要素により実行することができる。

【0120】

手順は、１組のデータレコードを受信する（８０２）。１組のデータレコードは少なくとも２つの次元を有し、データレコードの少なくとも幾つかはそれぞれ、少なくとも２つの次元のそれぞれに各データ値を含む。

【0121】

幾つかの例では、データは１つ又は複数の階層を含む。階層は少なくとも２つの次元を含み、次元の１つは階層の第１のレベルを表し、次元のうちの別の次元は、第１のレベルよりも低い階層の第２のレベルを表す。

【0122】

手順は、基数により順序づけられた１組のグループ化されたデータレコードを生成する（８０４）。これは、少なくとも２つの次元のうちの第１の次元のデータ値に従って、データレコードをサブセットにグループ化することを含み、第１の次元で利用可能なデータ値数は、第２の次元で利用可能なデータ値数よりも少ない。手順は、第１の次元のデータ値及びソート基準に従って、グループ化されたデータレコードのサブセットを配置することも含む。手順は、グループ化されたデータの各サブセットのデータレコードが第２の次元の値によりソートされるように、少なくとも２つの次元のうちの第２の次元のデータ値に従って、グループ化されたデータレコードのサブセットのデータレコードを配置することを更に含む。

【0123】

グループ化されたデータレコードのいかなる特定のデータレコードも、要求に応答して特定のデータレコードのデータを識別するのに使用することができる主キーを含む。例えば、主キーは、特定のデータレコードのデータ値の少なくとも幾つかで構成し得、主キーは、特定のデータレコードの少なくとも２つの次元の少なくとも１つの特徴から計算される要素を含むこともできる。計算される要素は詳細マスクであることができ、詳細マスクは、次元の１つ又は複数の詳細レベルのスカラー表現である。幾つかの実施態様では、グループ化されたデータレコードの少なくとも幾つかは、詳細マスクに従ってソートされる。詳細マスクを含め、このようにしてグループ化されたデータの例を図５Ａ〜図５Ｃに示す。

【0124】

手順は、グループ化されたデータレコードの組を含む少なくとも１つのフラットファイルを生成する（８０６）。次に、生成された少なくとも１つのフラットファイルは、非一時的コンピュータ可読媒体に記憶される。

【0125】

幾つかの例では、グループ化されたデータレコードは、ブロックの形態で１つ又は複数のフラットファイルに記憶される。これらの各ブロックは、データレコードの１つ又は複数を含む。さらに、各ブロックに１つ又は複数のエントリを含むインデックスを生成することができる。各ブロックのエントリは、各ブロックを識別する主キーフィールドと、１つ又は複数のフラットファイル内の各ブロックの記憶ロケーション、例えば、どのフラットファイル及びフラットファイルのどの行か（復帰改行、改行、別の種類の行区切り、又はこれらの１つ又は複数で隔てられた行を有するフラットファイルにおいて）を識別するロケーションフィールドとを含むことができる。インデックスを使用して、受信した主キー値に基づいて、主キーフィールド及びロケーションフィールドを使用することにより、受信した主キー値を含む主キー値範囲に対応するデータレコードを含むブロックの１つの記憶ロケーションを識別することができる。ブロック及びインデックスの例については、図３に関連して上述した。

【0126】

手順８００により記憶されるデータは、事前に計算される値を含むことができる。例えば、手順は、次元の中の異なる詳細レベルの１つ又は複数の値を事前に計算することを含むことができる。この例では、事前に計算される値は、次元の異なる詳細レベルで集計される尺度を表し、グループ化されたデータレコードは、事前に計算される値の少なくとも幾つかを含む。

【0127】

データが記憶されると、データは、例えば、そのようなＳＱＬクエリ又は別の種類のクエリクエリに応答して検索することができる。

【0128】

図９は、クエリを処理して、リレーショナルデータベース以外の記憶装置、例えば、１つ又は複数のフラットファイル内のデータキューブのデータにアクセスする手順９００を表すフローチャートを示す。１組のデータレコードは少なくとも２つの次元を有し、データレコードの少なくとも幾つかはそれぞれ、少なくとも２つの次元のそれぞれに各データ値を含む。手順９００は、例えば、図２に示されるレコード記憶・検索システム２００の構成要素により実行することができる。幾つかの例では、手順９００を使用して、図８に関連して上述した手順８００により記憶されたデータにアクセスする。

【0129】

手順はクエリを受信する（９０２）。通常、クエリは、１組のデータレコードの少なくとも１つの次元に対する少なくとも１つの制約を含む。

【0130】

手順は、クエリに基づいて、データレコードを記憶しているデータキューブを識別する（９０４）。例えば、クエリは、データキューブに対応するデータソースを指定し得る。データキューブ１００の例は図１Ａ〜図１Ｄに示され、データキューブは、例えば、図２に示されるレコード記憶装置２０６に記憶することができる。

【0131】

手順は、クエリの少なくとも１つの詳細マスクを計算し（９０６）、詳細マスクは１つ又は複数の詳細レベルの表現を含み、各詳細レベルはデータレコードの次元の階層に対応する。

【0132】

手順は、リレーショナルデータベース以外のシステムから、計算された詳細マスクを使用して、クエリに応答して１つ又は複数のデータレコードを検索する（９０８）。幾つかの例では、データはデータレコードの形態で検索され、幾つかの例では、データレコードは１つ又は複数のフラットファイルに記憶される。

【0133】

幾つかの例では、手順９００は、少なくとも２つの次元の１つ又は複数の最小値及び最大値を計算することと、最小値及び最大値を使用して、システム内の対応するデータレコード範囲、例えば、１つ又は複数のフラットファイルに記憶されたデータの対応するブロックにアクセスすることとも含む。幾つかの実施態様では、第１の主キーが開始ロケーションを指定し、第２の主キーが終了ロケーションを指定するように、２つの主キーを使用して、データレコードの開始ロケーション及び終了ロケーションを識別する。

【0134】

幾つかの例では、手順９００は、第２の次元に対する制約に基づいて、第１の次元に対する制約を識別することと、識別された制約をクエリに追加することとを含む。この技法は、詳細に上述したように、「ハイドレート」と呼ばれることがある。幾つかの例では、第１の次元に対する制約は、データキューブに関連するセンサス、例えば、図６に関連して上述したセンサス６００に基づいて識別される。

【0135】

幾つかの例では、手順９００は、クエリが反復最適化の候補であると判断することと、サブクエリの少なくとも２つの反復を実行して、クエリを処理することとを含む。

【0136】

本明細書に記載されるシステム及び技法は、例えば、適するソフトウェア命令を実行するプログラマブル計算システムを使用して実施することができ、又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の適するハードウェア若しくは何らかの混成形態で実施することができる。例えば、プログラムされる手法では、ソフトウェアは、少なくとも１つのプロセッサ、少なくとも１つのデータ記憶システム（揮発性及び／又は不揮発性メモリ及び／又は記憶要素を含む）、少なくとも１つのユーザインターフェース（少なくとも１つの入力デバイス又はポートを使用して入力を受信し、少なくとも１つの出力デバイス又はポートを使用して出力を提供する）をそれぞれ含む１つ又は複数のプログラムされた又はプログラム可能な計算システム（分散、クライアント／サーバ、又はグリッド等の様々なアーキテクチャのものであり得る）で実行される１つ又は複数のコンピュータプログラムにプロシージャを含み得る。ソフトウェアは、例えば、データフローグラフの設計、構成、及び実行に関連するサービスを提供するより大きなプログラムの１つ又は複数のモジュールを含み得る。プログラムのモジュール（例えば、データフローグラフの要素）は、データリポジトリに記憶されたデータモデルに準拠するデータ構造又は他の編成データとして実施することができる。

【0137】

ソフトウェアは、ある時間期間（例えば、ダイナミックＲＡＭ等のダイナミックメモリデバイスのリフレッシュ期間の間の時間）にわたり、媒体の物理的特性（例えば、表面のピット及びランド、磁区、又は電荷）を使用して、揮発性若しくは不揮発性記憶媒体又は任意の他の非一時的媒体等の非一時的形態で記憶し得る。命令をロードする準備において、ソフトウェアは、ＣＤ−ＲＯＭ若しくは他のコンピュータ可読媒体（例えば、汎用若しくは専用計算システム若しくはデバイスにより可読）等の有形非一時的媒体で提供してもよく、又はネットワークの通信媒体を介して、実行される計算システムの有形非一時的媒体に送出してもよい（例えば、伝搬信号に符号化されてもよい）。処理の幾つか又は全ては、専用コンピュータで実行してもよく、又はコプロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は専用の特定用途向け集積回路（ＡＳＩＣ）等の専用ハードウェアを使用して実行してもよい。処理は、ソフトウェアにより指定された計算の異なる部分が異なる計算要素により実行される分散様式で実施し得る。そのような各コンピュータプログラムは、好ましくは、汎用又は専用プログラマブルコンピュータによりアクセス可能な記憶装置のコンピュータ可読記憶媒体（例えば、固体状態メモリ若しくは媒体又は磁気若しくは光学媒体）に記憶又はダウンロードされて、記憶装置媒体がコンピュータにより読み出された場合、本明細書に記載される処理を実行するようにコンピュータを構成し動作させる。本発明によるシステムは、コンピュータプログラムが構成される有形非一時的媒体として実施されると考えることもでき、この場合、そのように構成された媒体は、コンピュータに、本明細書に記載される処理ステップの１つ又は複数を実行させる特定の予め定義された様式で動作させる。

【0138】

本発明の幾つかの実施形態について説明した。それにも関わらず、上記説明が、本発明の範囲の限定ではなく、例示することが意図され、本発明の範囲が以下の特許請求の範囲により規定されることを理解されたい。したがって、他の実施形態も以下の特許請求の範囲内にある。例えば、本発明の範囲から逸脱せずに、様々な変更を行い得る。さらに、上述したステップの幾つかは、順序に依存しないものがあり、したがって、説明された順序とは異なる順序で実行することも可能である。

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6】

【図7】

【図8】

【図9】