集約ストレージ・アプリケーション、データベースおよびアウトラインの作成
集約ストレージ・データベースを含める集約ストレージ・アプリケーションを作成する必要があります。 集約ストレージ・アプリケーションに含めることができるデータベースは1つのみです。 集約ストレージ・アプリケーション、データベースおよびアウトラインは、次の方法で作成できます:
-
新しい集約ストレージ・アプリケーションおよびデータベースを作成します。 集約ストレージ・アウトラインは、データベースの作成時に自動的に作成されます。 アプリケーション・ワークブックを使用して作成できます。
-
ブロック・ストレージ・アウトラインを集約ストレージ・アウトラインに変換し、変換したデータベースおよびアウトラインを含む集約ストレージ・アプリケーションを作成します。
Essbaseでは、ブロック・ストレージ・アウトラインを集約ストレージ・アウトラインに変換するための次のシナリオがサポートされています:
-
非Unicodeブロック・ストレージ・アウトラインから非Unicode集約ストレージ・アウトライン
-
非Unicodeブロック・ストレージ・アウトラインからUnicode集約ストレージ・アウトライン
-
Unicodeブロック・ストレージ・アウトラインからUnicode集約ストレージ・アウトライン
次の変換シナリオはサポートされていません:
-
Unicodeブロック・ストレージ・アウトラインから非Unicode集約ストレージ・アウトライン
-
ブロック・ストレージ・アウトラインへの集約ストレージ・アウトライン
-
集約ストレージ・アウトラインへのディメンションおよびメンバーのロードの詳細は、「集約ストレージ・データベースでのディメンションの構築」および「集約ストレージ・データベースへのデータのロード」を参照してください。
集約ストレージ・アプリケーションおよびデータベース情報はブロック・ストレージ情報とは異なり、集約ストレージ・アプリケーションおよびデータベースには特定のネーミング制限が適用されます。 「固有の差異」を参照してください。
ブロック・ストレージ・アウトラインを集約ストレージ・アウトラインに変換するには、create outline MaxL文を使用できます。
ノート:
ファイル・システムを使用してブロック・ストレージ・アウトラインを集約ストレージ・アプリケーションにコピーしないでください。
集約ストレージ・アプリケーションまたはデータベースを作成するには、アプリケーション・ワークブックを使用するか、次のMaxL文を使用します:
-
create application
-
create database
階層
集約ストレージ・アウトラインおよびブロック・ストレージ・アウトラインでは、ディメンションは、レベル内の関連するレベルおよびメンバーの1つ以上の階層を含むように構造化されます。 たとえば、ASOsamp.Sampleデータベースの時間ディメンションには、次に示すように、MTD、QTDおよびYTDという階層が含まれます:
図35-1 時間ディメンションの複数の階層およびメンバーを示すアウトライン

集約ストレージ・データベースでは、次の2つのタイプの階層を作成できます:
-
保管済
-
Dynamic
2つのタイプの階層には、異なる利点と制限があります。 ディメンションには、両方のタイプの階層を含めることができます。 ディメンションで複数の階層を使用するには(格納されているすべての階層であっても)、そのディメンションに対して複数の階層を有効にする必要があります。
Essbase webインタフェースで、ディメンションの複数の階層をキューブ情報プロパティとして有効にします。
ディメンション・メンバーを複数の階層が使用可能としてタグ付けすると、ラベルのみが自動的にタグ付けされます。
ディメンションを複数の階層が使用可能としてタグ付けしない場合、ディメンションは保管階層として自動的にタグ付けされます(ただし、勘定科目としてタグ付けされたディメンションは、動的階層として自動的にタグ付けされます)。
ノート:
複数階層有効のディメンションの最初の階層は保管階層である必要があります。
保管階層
保管階層のメンバーは、アウトライン構造に従って集計されます。 集約ストレージ・データベースは集約用に最適化されているため、保管階層のデータ値の集約は非常に高速です。 この高速集計を可能にするために、保管階層のメンバーには次の制限があります:
-
保管階層には、連結なし(~)演算子(ラベルの下のみのメンバーのみ)または加算(+)演算子を含めることができます。
-
保管階層に式を含めることはできません。
保管階層には、ラベルのみのメンバーに関する制限があります。 「アウトラインの違い」を参照してください。
「代替階層」に表示される階層では、すべての商品階層とハイ・エンド商品階層が格納されています。 すべての商品メンバーとハイ・エンド商品メンバーは階層の最上位であり、どちらも保管階層の最上位としてタグ付けされています。
Essbase webインタフェースでは、格納された階層を情報プロパティとして指定します。
import database MaxL文を使用して、階層の最上位メンバーを保管階層の最上位としてタグ付けできます。
次のメンバーは、保管階層の最上位としてタグ付けできます:
-
ディメンション・メンバー(世代1)。 ディメンション・メンバーが保管階層の最上位としてタグ付けされている場合、ディメンション全体が単一の保管階層とみなされ、ディメンション内の他のメンバーは保管階層の最上位または動的階層の最上位としてタグ付けできません。
-
ディメンション・メンバーの子(世代2)。 世代2メンバーが保管階層の最上位としてタグ付けされている場合、ディメンションのすべての世代2メンバーも保管階層の最上位または動的階層の最上位としてタグ付けされている必要があります。 ディメンションの最初の階層は保管階層である必要があります。
勘定科目タグが付けられたディメンションは自動的に動的ディメンションとみなされます。 勘定科目ディメンションを保管階層に指定できません。
動的階層
動的階層を評価するために、Essbaseでは、メンバーおよび式が集約ではなく計算されます。 メンバーおよび式が評価される順序は、解決順プロパティによって定義されます。 「計算順序」を参照してください。
取得時に、Essbaseは必要なメンバーの組合せを計算し、必要なアウトライン・メンバー式を計算します。 動的階層が計算されるため、格納階層から取得されるデータよりもデータ取得時間が長くなる場合があります。 ただし、データベースを設計する場合、動的階層には次の利点があります:
-
任意の集計演算子を含めることができます。
-
式を持つことができます。
Essbase webインタフェースでは、動的階層を情報プロパティとして指定します。
import data MaxL文を使用して、階層の最上位メンバーを動的階層の最上位としてタグ付けできます。
次のメンバーは、動的階層の最上位としてタグ付けできます:
-
ディメンション・メンバー(世代1)-ディメンション・メンバーが動的階層の最上位としてタグ付けされている場合、ディメンション全体が単一の動的階層とみなされ、ディメンション内の他のメンバーは動的階層の最上位または保管階層の最上位としてタグ付けできません。
-
ディメンション・メンバーの子(世代2)-世代2メンバーが動的階層の最上位としてタグ付けされている場合、ディメンション内のすべての世代2メンバーも動的階層の最上位または保管階層の最上位としてタグ付けされる必要があります。 ディメンションの最初の階層は保管階層である必要があります。
ノート:
メンバーのすべての子に連結なし演算子(~)がある場合、そのメンバーはタグ付きラベルのみである必要があります。
ディメンション・タグ付き勘定科目は、自動的に動的階層とみなされます。 勘定科目ディメンションを保管階層に指定できません。
Essbaseでは、集約ビューの動的階層メンバーを選択できません。
代替階層
代替階層は、次のいずれかの方法でモデル化できます:
-
属性ディメンションとして。属性を使用して、ディメンション内のメンバーを論理的に分類します(たとえば、Productディメンションには、サイズやフレーバなどの属性を設定できます)。
ノート:
属性ディメンションを使用して代替階層を作成する場合、基本ディメンションのメンバーを含む属性ディメンションのメンバーのクロス集計レポート問合せを作成できます。 たとえば、製品販売情報のクロス集計レポートでは、列見出しとしてサイズ属性(小、大など)を表示し、行見出しとして製品を表示できます。 共有メンバーを使用して代替階層を作成する場合、プライマリ階層の参照メンバーと共有メンバーの同等のクロス集計レポート問合せを作成することはできません。
-
共有メンバーの階層として。 代替階層には、アウトライン内の前の階層の参照メンバーを指す共有メンバーがあります。 共有メンバーは、参照されるメンバーとは異なる階層に従ってロールアップされます。 動的階層の共有メンバーは式を持つことができます。 次の表に、ASOsamp.Sampleデータベースの階層を示します。 次の図に、Productsディメンションを示します。
表35-1 ASOsamp.SampleのProductディメンションの階層および代替階層の例
製品 | 階層 | 代替階層(共有メンバーを含む) |
---|---|---|
フラット・パネル |
製品、全商品、パーソナル・エレクトロニクス、家庭用エンターテインメント、テレビ |
製品、ハイ・エンド製品 |
HDTV |
製品、全商品、パーソナル・エレクトロニクス、家庭用エンターテインメント、テレビ |
製品、ハイ・エンド製品 |
図35-2 Productディメンションの代替階層ハイ・エンド商品を表示する集約ストレージ・アウトライン

集約ストレージ・アウトラインで代替階層を作成する場合は、次の制限が適用されます:
-
メンバーの参照インスタンスは、アウトラインでメンバーの共有インスタンスより前に出現する必要があります。 たとえば、「図35-2」では、メンバーHDTVは、ハイ・エンド商品の代替階層の共有メンバーとして出現する前に、すべての商品階層で発生します。
-
複数の階層が使用可能なディメンションの最初の階層に共有メンバーを含めることはできません。
-
保管階層ディメンションが共有メンバーを持つことはできない。 複数階層ディメンション内の保管階層は、共有メンバーを持つことができます。
-
値が二重にカウントされないようにするために、「保管済」階層に同じ共有メンバーの複数のコピーを含めることはできません。 たとえば、保管階層に共有メンバーとその祖先を含めることはできません。 「図35-2」では、「Televisions」という共有メンバーを「High End Merchandise」の子として追加することはできません。追加すると、「Televisions」がその子の兄弟になり、「Flat Panel」と「HDTV」という共有メンバーが追加され、「Flat Panel」と「HDTV」の値が2回追加されるためです。
-
メンバーの参照インスタンスは、共有メンバーと同じディメンションにある必要があります(ブロック・ストレージ・アウトラインの場合も同じ)。
-
保管階層には、参照インスタンスと同じメンバーの共有インスタンスを含めることはできません。
-
保管階層に動的階層メンバーの共有インスタンスを含めることができるのは、動的階層メンバーが式のないレベル0メンバーである場合のみです。
ノート:
集約ストレージ・データベースでは、共有メンバーは、その参照メンバーに関連付けられている属性を自動的に共有します。
属性ディメンション
このトピックでは、属性ディメンションに関する集約ストレージ・データベースとブロック・ストレージ・データベースの違いについて説明します。 このトピックの情報を使用するには、ブロック・ストレージ・データベースの属性ディメンションの概念を理解している必要があります。 属性の操作を参照してください。
集約ストレージ・データベースで使用する場合、次の情報が属性ディメンションに適用されます:
-
属性ディメンションに使用できるのは、加算(+)集計演算子のみです。
-
特定の属性ディメンションについて、すべての関連付けがベース・ディメンションの1つのレベルにある必要があります。 たとえば、ASOsamp.Sampleデータベースでは、ストア・マネージャ属性ディメンションの関連付けはストア・ディメンションのレベル0です。 属性関連付けには、次の制限が適用されます:
-
レベル0: 式を持たない動的階層または保管階層のレベル0のメンバーに属性を関連付けることができます。
-
Non-level 0: 属性を関連付けることができるのは、プライマリ・ストア階層の上位レベル・メンバーのみです。
-
属性ディメンションには階層タイプがありません。 属性ディメンションを動的または保管階層として指定することはできません。 Essbaseは、属性ディメンションをベース・ディメンションの保管済代替階層として処理します。 たとえば、ASOsamp.Sampleデータベースでは、Essbaseはストア・マネージャ属性ディメンションを、ストア・マネージャ・ディメンションの保管済代替階層であるかのように処理します。
問合せトラッキングを使用する場合、Essbaseは属性ディメンション・データに対する問合せを考慮し、属性ディメンション・メンバーを集約ビューの選択に含めることができます。 「使用状況に基づいたビューの選択」および「集約ストレージ・データベースの計算」を参照してください。
ノート:
レベル0以外のメンバーに関連付けられている属性メンバーに対する問合せは、レベル0以外のメンバーの子孫の値を戻します。 集約ストレージ・データベースでの属性メンバーに対する問合せのこの動作は、ブロック・ストレージ・データベースでの動作とは異なります。
属性問合せの設計上の考慮事項
属性問合せデータに基づいてビューを選択および構築する場合、属性データに対する一部の問合せは、取得時に常に動的に計算されるため、問合せのパフォーマンスに影響する可能性があります。
属性ディメンション・メンバーを含むすべての問合せには、ベース・ディメンションのメンバーも1つ以上含める必要があります。 問合せに単一の属性ディメンションとすべてのディメンション・メンバーの合計が含まれる場合、Essbaseは問合せデータを集計するため、問合せのパフォーマンスが向上する可能性があります。 それ以外の場合、Essbaseでは取得時に問合せを計算する必要があります。
次の表では、属性問合せのタイプと、Essbaseによる問合せの計算方法について説明します:
表35-2 属性問合せと計算パフォーマンス
属性問合せタイプ | 問合せ計算タイプ |
---|---|
問合せには、すべての基本ディメンション・メンバーと、1つの属性ディメンションのメンバーの合計が含まれます。 |
Essbaseでは問合せデータを集計できるため、問合せのパフォーマンスが向上する可能性があります。 |
問合せには、基本ディメンションのメンバーおよび複数の属性ディメンションのメンバーが含まれます。 |
Essbaseでは、取得時にレベル0の入力データに基づいて問合せが計算されます。 |
問合せには、基本ディメンション・メンバー(またはラベルのみとしてタグ付けされているディメンション・メンバー)の子メンバーと、1つの属性ディメンションのメンバーが含まれます。 |
Essbaseでは、レベル0の入力データまたはベース・ディメンションの集計からのデータに基づいて、取得時に問合せが計算されます。 |
次の概要図では、RealDimensionはそのすべての子孫の合計です(ラベルのみとしてタグ付けされていません)。 問合せに単一の属性ディメンション(AttributeDimension1など)のメンバーが含まれ、基本ディメンション・メンバー(RealDimension)と交差する場合、Essbaseはデータの集約セルを構築できるため、問合せのパフォーマンスが向上する可能性があります。
ただし、次の問合せは常に取得時に計算されます:
-
属性ディメンション(AttributeDimension1など)のメンバーのデータをリクエストする問合せおよびRealDimensionの子は、レベル0の入力データまたは集計からのデータに基づいて取得時に動的に計算されます。
-
複数の属性ディメンション(AttributeDimension1やAttributeDimension2など)および基本メンバー・ディメンション(RealDimensionなど)のデータをリクエストする問合せは、レベル0の入力データに基づいて取得時に動的に計算されます。
図35-3 属性問合せの例のアウトライン
集約ストレージ・アウトラインの設計上の考慮事項
このトピックでは、集約ストレージ・データベース・アウトラインを作成する際の主な設計上の考慮事項を示します。 これらの設計上の考慮事項の実装例は、ASOsamp.Sampleデータベースを参照してください。 集約ストレージ・アウトラインを設計する際には、次の情報を考慮してください:
-
可能なかぎり(動的階層ではなく)格納された階層を使用します。
-
代替階層(共有メンバー)は、必要な場合にのみ使用します。
-
階層の数を最小化します。 (たとえば、格納された階層を追加するたびに、ビューの選択速度が低下し、集計データのサイズが増加する可能性があります)。
-
階層が最初の階層の小さいサブセットである場合は、小さい階層を動的階層にすることを検討してください。 考慮事項には、階層データを問い合せる頻度や、取得時に動的に問い合せる場合の問合せのパフォーマンスへの影響が含まれます。
-
属性のパフォーマンスは、保管階層のメンバーの場合と同じです。
-
基本メンバーに対する属性の関連付けレベルが高いほど、取得問合せが高速になります。 (「属性問合せの設計上の考慮事項」も参照してください)。
集約ストレージの問合せ設計の考慮事項
複数の階層を持つディメンションからデータを問い合せる場合、次の方法でデータを問い合せると、問合せのパフォーマンスが向上する可能性があります:
-
問い合せる階層を選択します。
-
ナビゲートして詳細データを検索します(たとえば、Smart Viewの階層にズーム・インします)。
動的階層メンバーと保管済階層メンバーを同じ問合せに含めるには、問合せのパフォーマンスを低下させる大規模な内部メモリー・キャッシュが必要になる場合があります。
集約ストレージ・データベース・アウトラインの64ビット・ディメンション・サイズ制限
集約ストレージ・データベース・アウトラインは、ディメンション当たり64ビットを超えることはできません。
ディメンションに必要なビット数は、代替階層および関連する属性ディメンションのレベル0の子を含む、レベル0の子で使用される最大ビット数です。 メンバー採番の目的で、属性ディメンションは基本ディメンションの代替階層として扱われます。
通常、ディメンションのメンバーに必要なビット数を決定する式は、次のように表すことができます:
#_bits_member’s_parent + log(x)
ここで、xは親の子の数です。
たとえば、メンバーの親が5ビットを必要とするメンバーAで、Aに10個の子がある場合、各子が必要とするビット数は次のようになります:
5 +log(10) = 9 bits
通常、ディメンションまたは階層の最上位メンバーは0ビットを使用します。 ただし、1つ以上の最上位世代がラベルのみのメンバーで構成されている場合、ラベルのみのメンバーはメンバー番号を受け取りません(保管済メンバーとみなされないため)。 したがって、最初の非ラベルのみの世代にxメンバーが存在する場合、それらのメンバーはlog(x)ビットを使用します。 その下の残りの子には、通常どおり番号が付けられます。
同様に、ディメンションまたは階層が動的な場合、保管または共有されているレベル0のメンバーのみがメンバー番号を受け取ります。 これらのメンバーに必要なビット数はlog(x)で、xは保管または共有されているレベル0メンバーの数(式メンバーではないレベル0メンバーの数)です。
ただし、代替階層に格納されている(共有されていない)レベル0のメンバーがある場合、ディメンション内のすべての階層の各メンバー(関連付けられている属性ディメンションを含む)では、追加のlog(x)ビットが使用されます。xは、この基本ディメンションの階層および関連付けられている属性ディメンションの合計数です。
次の例では、ASOsamp.SampleデータベースでProductsディメンションを使用します:

Productsディメンションには2つの階層があります: 代替階層であるすべての商品およびハイ・エンド商品。 ハイ・エンド商品には、レベル0の保管済メンバーが1つあります: 保管済メンバー。 Productsディメンションには関連付けられた属性ディメンションがありません。
メンバーすべての商品およびハイ・エンド商品では、log(2) = 1ビットが使用されます。
ノート:
代替階層のハイ・エンド商品にレベル0のメンバーが格納されていない場合、各階層(および関連する属性ディメンション)の最上位メンバーはそれぞれ0ビットを使用します。
各レベル0の子に必要なビット数の計算:
All Merchandise = 1 bit
Personal Electronics, Home Entertainment, Other = 1 + log(3) = 3 bits
Digital Cameras/Camcorders, Handhelds/PDAs, Portable Audio = 3 + log(3) = 5
Children of Digital Cameras/Camcorders = 5 + log(3) = 7
Children of Handhelds/PDAs = 5 + log(3) = 7
Children of Portable Audio = 5 + log(2) = 6
Televisions, Home Audio/Video = 3 + log(2) = 4
Children of Televisions = 4 + log(5) = 7
Children of Home Audio/Video = 4 + log(4) = 6
Computers and Peripherals = 3 + log(1) = 3 **
Systems, Displays, CD/DVD drives = 3 + log(3) = 5
Children of Systems = 5 + log(2) = 6
High End Merchandise = 1 bit
Flat Panel, HDTV, Stored Member = 1 + log(3) = 3 bits
メンバー・コンピュータおよび周辺機器には、その親であるその他と同じビット数(3)があります。
Productsディメンションのレベル0の子によって使用される最大ビット数は7です(デジタル・カメラの子およびテレビの子)。 したがって、Productsでは7ビットが使用され、これはディメンション・サイズの制限である64ビットより小さくなります。
ディメンション・サイズが64ビットを超える場合:
-
Essbaseでは、アウトラインの保存時に次のエラーが生成されます:
Hierarchy [DimensionName] is too complex. It exceeds the maximum member number width of 64 bits. See application log for details.
-
Essbaseでは、次のようなメッセージがアプリケーション・ログに記録されます:
Member number for member [level0member] requires [65] bits to encode Member [level0member] contributes [5] bits to member number Member [level1parent] contributes [20] bits to member number Member [level2parent] contributes [20] bits to member number Member [level3parent] contributes [20] bits to member number
エラーを修正するには、次のいずれかの推奨事項を使用します:
-
可能な場合は、メッセージで参照されているメンバーの兄弟を削除してください。 兄弟の数を2乗して減らすと、1ビット節約できます。 たとえば、メンバー番号に5ビットを寄与するlevel0memberに、それ自体を含む18個の兄弟があるとします。 兄弟の数を16以下に減らすと、log(16)が4であるため、1ビット節約できます。 同様に、兄弟の数を8以下に減らすと、2ビットが節約されます。
-
メッセージで参照されているメンバーの兄弟を再分類します。 たとえば、level0memberの18個の兄弟の半分を、子の数が少ない別の親に移動します。 または、新しい親をlevel1parentの兄弟として作成し、level1parentの子の半分を新しいメンバーの下に移動します。 このアプローチにより、1ビットを節約できます。
-
一部の中間レベルを結合します。 たとえば、level0memberとそのすべての兄弟をlevel2parentの子になるように移動してから、level1parentを削除します。 このアプローチはより関係がありますが、多くのビットを節約できます。
集約ストレージ・データベースの圧縮ディメンションの理解
デフォルトでは、集約ストレージ・データベースの圧縮ディメンションは勘定科目ディメンションです。 圧縮ディメンションを変更すると、データベース全体の再構築がトリガーされます。 Essbaseでは、圧縮ディメンションは単一の動的階層である必要があります。 ディメンションの階層設定が異なる場合(複数の階層など)、ディメンションは自動的に単一の動的階層に設定されます。 元の階層設定は失われます(異なるディメンションを圧縮として設定しても、元の階層設定は返されません)。 属性ディメンションを圧縮ディメンションにしたり、属性が関連付けられているディメンションにすることはできません。
圧縮ディメンションの選択は、パフォーマンスに大幅に影響を与える可能性があります。 圧縮ディメンションの適切な候補は、取得のパフォーマンスを維持しながらデータ圧縮を最適化するものです。 このトピックでは、最適な圧縮ディメンションの選択に関する情報を提供します。
ノート:
このトピックの情報は、ロードされたデータベースに適用されます。 「集約ストレージ・データベースへのデータのロード」を参照してください。
取得パフォーマンスの維持
圧縮ディメンションは動的に計算されるため、圧縮ディメンションを選択する際には、動的に計算されるディメンションの設計上の考慮事項を考慮する必要があります。 動的ディメンションは取得時に計算されるため、格納されている階層よりもデータ取得時間が長くなります。
多数のレベル0メンバーを持つディメンションが圧縮としてタグ付けされている場合、上位レベルの問合せでは多くのレベル0メンバーを取得する必要があるため、時間がかかります。 ユーザーが多数の上位レベルの取得を大規模なディメンションで実行する場合、圧縮ディメンションには適していません。
圧縮見積り統計の表示
MaxLでは、詳細な圧縮および問合せ統計を表示できます。 取得のパフォーマンスに影響する保管済レベル0メンバーの数、圧縮に影響する平均バンドル充填および平均値の長さ、およびレベル0のサイズを表示できます。
問合せおよび圧縮の詳細な統計を表示するには、query database MaxL文の集約ストレージ・バージョンを使用できます。
圧縮および問合せに関連する各統計の次の説明を参照してください。
レベル0のメンバーを保管しました
保管されているレベル0メンバーの数が多いディメンションは、タグ付けされた圧縮では適切に実行されません。 動的に計算されるディメンションと同様に、圧縮ディメンションからの上位レベルの取得は一般的に遅くなります。
平均バンドル充填
値の間に多数の#MISSING
データがあるアウトライン全体に分散するのではなく、ディメンションまたは階層の連続するメンバーに値がグループ化されている場合は、圧縮がより効果的です。 Essbaseでは、メンバーごとに別々に格納するのではなく、グループのロケーションと内容に関する情報を格納することでメモリーを節約します。 平均バンドルの入力は、グループに保管されている値の平均数です。 これは1から16の間となり、16が最適です。 平均バンドルの入力がより高い圧縮ディメンションを選択するということは、データベースがより適切に圧縮されることを意味します。
一部のアウトラインでは、頻繁に移入されるメンバーがグループ化されるように圧縮ディメンション内の数値を順序付けすることで圧縮を改善できます。 移入されるメンバーをグループ化すると、より多くの値が各バンドルに適合し、平均バンドルの入力の値が高くなり圧縮効果が向上します。
平均値の長さ
平均値の長さは、セルに格納されている値に必要な平均ストレージ・サイズ(バイト単位)です。 これは2バイトから8バイトの間となり、2バイトが最適です。 圧縮しない場合、セルに値を保管するには8バイト必要です。 圧縮する場合、値の長さに応じて、必要なバイト数はより少なくなります。 たとえば、10.050001は圧縮しても8バイトが必要ですが、10.05で必要なのは2バイトのみです(圧縮する場合保管に4バイト必要)。 平均値の長さがより小さいディメンションでは、データベースの圧縮効率が高くなります。
データ値の小数点以下を2桁以下に丸めると平均値の長さを短縮でき、圧縮効率が向上します。
予期されるレベル0サイズ
このフィールドは、圧縮されたデータベースの推定サイズを示します。 適切なレベル0サイズの値が小さい場合、このディメンションを選択するとより適切な圧縮が期待できることを示します。
集約ストレージ・アウトラインの検証
集約ストレージ・アウトライン・ファイルは、ブロック・ストレージ・データベース・アウトライン・ファイルと同じファイル拡張子(.otl
)を持ち、同等のディレクトリ構造に格納されます。
アウトラインを保存すると、Essbaseによってエラーが検証されます。 アウトラインを保存する前に、その精度を確認することもできます。 一部のブロック・ストレージ・データベース機能は集約ストレージ・データベースには適用されず、検証プロセスでは集約ストレージ・データベースのルールが考慮されます。 「集約ストレージとブロック・ストレージの比較」を参照してください。
アウトライン・ページング
集約ストレージ・データベース・アウトラインはページング可能です。 この機能により、大規模なデータベース・アウトラインのメモリー使用量が大幅に削減される可能性があります。 集約ストレージ・データベースの場合、Essbaseはデータベース・アウトラインの一部をメモリーにリロードします。 その後、データ取得時に、Essbaseは必要に応じてアウトラインの他の部分をメモリーにページングします。
集約ストレージ・データベースを作成すると、アウトラインがページング可能な形式で作成されます。 集約ストレージ・アウトライン変換ウィザードを使用して既存のブロック・ストレージ・アウトラインを集約ストレージに変換すると、アウトラインは自動的にページング可能なフォーマットに変換されます。
アウトラインをメモリーにページングすると、Essbaseで非常に大きなアウトライン(たとえば、100万人以上のメンバー)を処理できますが、データ取得時間が長くなる可能性があります。
ノート:
ページング可能なアウトラインを持つ集約ストレージ・データベースにはメモリー・ページが含まれているため、そのアウトライン・ファイルはバイナリ・ブロック・ストレージ・データベースのアウトライン・ファイルより大きくなる場合があります。
アウトライン・ページング制限
構築可能なアウトラインの最大サイズ(メンバー数)は、いくつかのファクタによって異なります:
-
Essbaseで使用可能なメモリー
-
他の用途に割り当てられたEssbaseのメモリー量
-
各メンバーに必要なメモリー量(および各メンバーの別名)
Essbaseは、起動時に約40 MBのメモリーを使用します。 また、様々なキャッシュには次のメモリー割当てが必要です:
-
アウトライン・ページング・キャッシュ: 8 MB
-
集約ストレージ・データ・キャッシュ: 32 MB
-
集約ストレージ集約キャッシュ: 10 MB
したがって、Essbaseの初期メモリー・フットプリントは約90 MBです。 さらに、受信問合せリクエストを処理するためにメモリーを割り当てる必要があります。 このために予約する一般的なメモリーは約300 MBです。 したがって、Essbaseに割り当てられる合計メモリーは390 MBです。
1.85 GBのアドレス可能メモリーを搭載したWindowsシステムでは、アウトラインの構築とロードに使用できる容量は約1.46 GB (1.85 GB - 390 MB = 1.46 GB)です。
アウトラインの最大サイズは、ディメンション構築を使用して構築されているか、Essbaseにすでにロードされているアウトラインから構築されているかによって異なります。
ディメンション構築制限
ディメンション構築を使用してアウトラインを構築するために、Essbaseでは、メンバーごとに約100バイト、メンバー名のサイズ、およびメンバーのすべての別名のサイズ(最大10個の別名が許可されます)が割り当てられます。
平均メンバー名が15文字で、メンバーごとに別名(20文字)が1つある(シングルバイト・コードページを使用した)アウトラインの例の場合、追加される各メンバーのメモリー要件は次のとおりです:
100 + 15 + 20バイトの= 135バイト
ディメンション構築に追加できるメンバーの合計数は、使用可能なメモリー(1.46 GBまたは153,092,060バイト)をメンバー当たりのバイト数(135)で除算した値(約100万メンバー)です。
アドレス可能なメモリーが2 GBを超えるシステムでは、使用可能な追加メモリーに比例してアウトラインを大きくできます。
ディメンションの構築が完了すると、dbname .otn
ファイルがデータベース・ディレクトリに保存されます。 .otn
ファイルはアウトラインの再構築プロセスの入力として使用され、古いアウトラインが新しいアウトラインに置き換えられます。 再構築時には、アウトラインの2つのコピーがメモリーにロードされます。古いコピー(空の可能性がある)と新しいコピーであるため、再構築できるアウトラインの最大サイズは古いアウトラインのサイズによって異なります。
空のアウトラインで始まるディメンション構築では、1つのアウトラインのみがメモリーにロードされます。
ロードされたアウトライン制限
実行時または再構築時にEssbaseにロードされるアウトラインのメモリー要件は、ディメンション構築のメモリー要件とは異なります。 Essbaseでは、メンバー当たり約60バイト、メンバー名のサイズ、5バイト、メンバーのすべての別名のサイズ(最大10個の別名が許可されます)および5バイトが割り当てられます。 平均メンバー名が15文字で、メンバーごとに別名(20文字)が1つあるアウトラインの例では、追加される各メンバーのメモリー要件は次のとおりです:
60 + 15 + 5 + 20 + 5バイト= 105バイト/メンバー
1.46 GBの使用可能なメモリーがある場合、ロードできるアウトラインの最大サイズは1400万メンバー(1.46 GB/105バイト)です。
1400万人のメンバーは、再構築中にロードされた2つのアウトラインの合計です。 たとえば、既存のアウトラインに5百万のメンバーがある場合、新しいアウトラインには最大で9百万のメンバーを含めることができます。 増分ディメンション構築では、アウトライン・サイズを最大にするために、小さい方のディメンションを最初に構築し、大きい方のディメンションを最後に構築することをお薦めします。
集約ストレージ・アウトライン・ファイルの圧縮
集約ストレージ・アウトラインのアウトライン・ファイル(.otl
)は、メンバーが追加または削除された場合など、アウトラインの変更に応じてサイズが大きくなります。 アウトライン・ファイルのサイズを小さくするには、圧縮します。 アウトライン・ファイルが圧縮された後、メンバーが追加または削除されると、以前のようにファイルは増大し続けます。
アウトライン・ファイルを圧縮すると、Essbaseによってアウトラインが再構築され、他のユーザーまたはプロセスがデータベースをアクティブに使用していない場合にのみ実行できます。 アウトラインを圧縮しても、Essbaseはデータをクリアしません。
ノート:
アウトラインからメンバーが削除されると、アウトライン・ファイル内のそのメンバーの対応するレコードは削除済としてマークされますが、レコードはアウトライン・ファイルに残ります。 アウトライン・ファイルを圧縮しても、削除されたメンバーのレコードは除去されません。
アウトライン・ファイルを圧縮するには、alter database MaxL文を使用します。