プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド
12c (12.2.1.2.0)
E82973-02
目次へ移動
目次

前
前へ
次
次へ

集計指定作成の手動での記述

集計の永続性ウィザードを使用してスクリプト・ファイルを作成するかわりに、スクリプト・ファイルを手動で記述できます。集計の永続性ウィザードを使用することをお薦めします。

集計の作成時にOracle BIサーバーによってデータベースが変更されるのを望まない場合は、集計の永続性ウィザードでターゲットDDLを別のファイルに生成オプションを選択することによって、それを指定できます。集計の永続性ウィザードによって、空の集計表を作成するためのDDLファイル(集計準備スクリプト)が作成されます。この後、集計表にデータを移入するために、集計作成スクリプトを実行する必要があります。このオプションは、表作成のためのデータベースへのアクセスが制限されている場合に柔軟性を提供します。集計作成スクリプトを実行する前に集計準備スクリプトを実行する必要があることに注意してください。

この項では、次の項目について説明します。

作成プロセス時に課される制約

作成プロセス時に課される制約について説明します。

作成プロセス時には次の制約が課されます。

  • 有効なメジャー。有効なメジャーは有効な集計ルールを持っている必要があります。レベルベース・メジャーには次の制約が適用されます。

    • レベルが総計のエイリアスである場合、その集計指定のレベルのリスト内にそのディメンションが存在してはいけません。

    • このメジャーに定義される他のすべてのレベルは、その集計指定のレベルのリスト内に存在している必要があります。

    前述の制約が満たされない場合、集計指定全体が破棄されます。また、次のいずれかの条件に当てはまる場合、作成プロセスにおいてメジャーは無視されます。

    • メジャーがセッションまたはリポジトリ変数にマップされています。

    • メジャーが導出メジャーです。

    • メジャーにデフォルトの集計ルール(なし)が設定されています。

    無視されたメジャーは、必ずしも集計指定に影響するとは限りません。集計の作成には残りのメジャーが使用されます。

  • 有効なレベル。有効なレベルは有効な主キーを持つ必要があります。レベルが無効である場合、集計指定は破棄されます。また、次のいずれかの条件に当てはまる場合、レベルまたはその主キーの属性は無視されます。

    • 属性がセッションまたはリポジトリ変数にマップされています。

    • 属性が同一の論理表からのものではありません。

  • 有効な集計指定。有効な集計指定は次のプロパティを持ちます。

    • 名前の長さが1 - 18文字です(1文字、18文字も可)。

    • 1つ以上の有効なレベルが指定されています。

    • 1つ以上の有効なメジャーが指定されています。

    • 有効な接続プールを持つ必要があります。

    • 有効な出力コンテナを持つ必要があります(データベース/カタログ/スキーマ)。

    • 接続プールとコンテナは同一のデータベースに属する必要があります。

    • 各ディメンションに指定可能なレベルは1つのみです。

    • メジャーは同一のファクト表からのものでなくてはなりません。

    • 指定内のすべての論理コンポーネントは、同一のサブジェクト・エリアのものでなくてはなりません。

    レベルの集計はデータベース全体をスコープとするため、出力コンテナ内に同じ名前がすでに存在する場合、集計指定は無視されます。ただし、同一のファクト集計名に対して異なるカタログまたはスキーマが指定される場合、同一のデータベース内の別のスコープであれば、同じ名前の複数のファクトを持つことが許可されます。

    ファクトに結合されていないディメンションが存在する場合、集計指定は破棄されることに注意してください。

集計指定作成の記述

すべてのメタデータの名前(論理ファクト列を除く)は完全修飾です。

操作には、作成と削除の2つのモードがあります。すべての集計指定を1つの集計作成文に含めることを強くお薦めします。

「ディメンション集計表への代理キーの追加」を参照してください。

集計指定のDelete文

スクリプト・ファイルの最初にはDelete文を置きます。新しい集計を作成する前にシステムによって生成された集計を削除することが不可欠です。

これにより、データの一貫性が保たれること、および作成操作の実行前に無効な集計や不完全な集計が削除されることが保証されます。集計を削除する文の構文は次のとおりです。

Delete aggregates [list of fully qualified physical table names];

次に例を示します。

Delete aggregates "src".."INCR"."fact_1", "src".."INCR"."fact_2";

オプションで、削除する物理表のカンマ区切りリストを含めることができます。含める表は、集計作成スクリプトの前回の実行によってシステムで生成されたものである必要があります。リストされたファクト表に結合されているすべてのディメンション表も削除されます。

ディメンション表が複数のファクト表に結合されている場合、それは、他の結合されている表もリストされていないかぎり削除されません。

ファクト表に加えて、Delete文を使用して、孤立ディメンション表を削除することもできます(これらは他のどのファクト表にも結合されていないディメンション表です)。集計作成が失敗すると、孤立ディメンション表が発生することがあります。

削除文によって、時系列キーが集計の永続性に追加された際に、時間ディメンションの論理表に追加された論理キーおよび論理列も削除されます。

集計指定のCreate文

Create文は、Delete文の後に実行する必要があります。

集計を作成する文の構文は次のとおりです。

Create|Prepare aggregates 
aggr_name_1
for  logical_fact_table_1 [(logical_fact_column_1, logical_fact_column_2, count_distinct_logical_fact_column_1 as_raw_values, ...)]   
at levels (level_1, level_2, …)
using connection pool connection_pool_name_1
in schema_name_1
[ ,aggr_name_2
for logical_fact_table_3 [(logical_fact_column_5, logical_fact_column_2,…)]   
at levels (level_3, level_2, …)
using connection pool connection_pool_name_2
in schema_name_2] ;

as_raw_valuesは、単一の集計ルールを持つ重複しない件数のメジャーを伴っている必要があります。単一の集計ルールには、ルールが1つだけあり、ディメンション・ベースではありません。

集計指定の複数の集計

次のガイドラインを使用して、1つの集計作成の文の中に複数の集計を指定します。

  • 複数の集計指定はカンマで区切り、集計作成スクリプト全体の終わりにはセミコロンを入力します。

  • このファイルでは、集計削除文は先頭に1つのみ指定するようにします。1回のETLの実行で削除は1回のみ実行されるようにします(リセットが必要な場合を除く)。

    注意:

    初回以降に実行されるすべての集計スクリプトでは、集計削除文は含めないようにするか、または以前に作成したすべての集計を削除するようにしてください。

集計指定のWhere句

オプションのWhere句をCreate文に追加できます。

Where句は集計するデータをフィルタし、断片化された集計またはベース・ファクト表のデータの断片のみの集計を作成します。Where句は、「論理表ソース」ダイアログにある「断片化の内容」フィールドも設定します。ほとんどの場合、断片化された集計の作成は問合せの高速化を最大化し、集計の作成および維持のコストを最小限に抑えます。

次の例は、断片化された集計を使用する場合を示しています。

  • 時間ディメンションを操作し、集計に過去3年のみのデータを含める場合。

  • 主に米国の売上を報告し、集計に米国のデータのみを含める場合。

次に示すのは、有効なWHERE句のCreate文の例です。

Create Aggregates
Revenue_By_Year
for  "sales"."sales" at levels("sales".timedim.year)   
where("sales"."time"."calendar year"=2007)
using connection pool aggrtarget.cp1
in aggrtarget..schema1

論理列の要件

Where句で指定する論理列は、次の要件を満たす必要があります。

  • 論理列は、ディメンションに属する必要があります。

  • 論理列が集計指定に含まれるディメンションに属する場合、集計のレベル以上である必要があります。

  • operational_operを使用する場合、論理列のデータ型はinlistの定数のデータ型と一致する必要があります。

    inclusion_operを使用する場合、論理列のデータ型はinlistのすべての定数のデータ型と一致する必要があります。

Where句の文法

集計の作成指定のWhere句の文法は、論理SQLフィルタのWhere文法のサブセットです。Oracle BIサーバーが集計の作成指定にサポートする文法は、論理SQLフィルタとわずかに異なります。

次のCreate文およびWhere句を確認してください。

create aggregate aggr1 for fact1 at levels(11,12...) where (filter_list) using ....

許容できる文法のルールは、次のとおりです。

filter_list ::= filter logical_oper filter_list

    | filter

    | '(' filter_list ')'

filter ::= logical_column relational_oper constant

    | logical_column inclusion_oper '(' inlist ')'

relational_oper ::= '=' | '!=' | '<' | '>' | '<=' | '>=' | 'like'

inlist ::= constant ',' inlist

    | constant

logical_oper ::= 'and' | 'or'

inclusion_oper ::= 'in' | 'not in'

ディメンション集計表への代理キーの追加

ファクト表とレベル集計表との結合オプションのデフォルトでは、レベル集計の主キーが使用されます。

このレベルの主キーが大きくて複雑である(多数の列で構成されている)場合、ファクト表への結合はコストが高くなります。代理キーは人工的に生成されたキーであり、通常は数字です。レベル集計表内の代理キーはこの結合を簡素化させ、ファクト表から不要な(レベルの主キーの)列が削除され、ファクト表のサイズが小さくなります。代理キーをディメンション(レベル)集計表に追加すると、ファクト表への結合を簡素化でき、問合せのパフォーマンスが向上することがあります。さらに、代理キーによって、各集計表が一意の識別子を持つようになります。

複数のファクト表間でレベルが共有される場合があります。この場合、あるファクトでは代理キーが使用され、別のファクトではディメンション集計の主キーがされる可能性があります。この状況を解決するためのいくつかのオプションを次に示します。

  • レベルに対して、代理キー、主キーのいずれが使用されるかを示すメタデータ・プロパティを設定します。

  • レベルの集計では常に代理キーを作成します(処理のコストは比較的低い)。ファクト集計をそれに結合する際に代理キーと主キーのいずれを使用するかについては、後で決定します。

各ディメンションに対して結合タイプを指定する方法の他に、スター全体で代理キーを使用するかどうかを指定する方法があります。これにより構文が簡潔になる場合がありますが、ユーザー・オプションの利用に制限が生じたり、集計作成プロセスの速度が低下したりすることがあります。

集計の作成/準備の構文について

集計の作成/準備のための構文には、変更箇所[Using_Surrogate_Key]が含まれています。

各レベルに代理キー・オプションを指定することができます。このオプションを指定しないと、ファクト表およびディメンション表は、レベル集計の主キーを使用して結合されます。

Create|Prepare aggregates 
aggr_name_1
[file output_file_name]
for  logical_fact_table_1 [(logical_fact_column_1, logical_fact_column_2,…)]   
at levels (level_1 [Using_Surrogate_Key], level_2, …)
using connection pool connection_pool_name_1
in schema_name_1
[ ,aggr_name_2
for logical_fact_table_3 [(logical_fact_column_5, logical_fact_column_2,…)]   
at levels (level_3, level_2, …)
using connection pool connection_pool_name_2
in schema_name_2] ;

集計の作成/準備からの代理キーの出力について

現在のプロセスへの変更は、リポジトリおよびデータベース内の物理メタデータ・レイヤーに制限されています。

Using_Surrogate_Key結合オプションを使用すると、次のような結果になります。

  • レベル集計の場合、次のようになります。

    • 物理メタデータでは次のようになります。

      • レベル集計表は、levelName_upgradeIDSKという名前の新しい列を持ちます(競合がチェックされます)。これは、ディメンション集計の代理キーの列です。全文字数が18文字を超える場合、levelNameは切り詰められることに注意してください。

    • データベースでは次のようになります。

      • レベル集計表は、levelName_upgradeIDSKという名前の対応する列を持ちます。ここでも、全文字数が18文字を超える場合、levelNameは切り詰められます。

      • これはRCOUNT()を使用してデータが設定されます。

  • ファクト集計の場合、次のようになります。

    • 物理メタデータでは次のようになります。

      • ファクト集計表には、レベルの主キーの列は含まれません。

      • かわりに、レベル集計の代理キーに対応する新しい列が表に追加されます。

      • この列の型はレベルの代理キーと同じです。

      • この列の名前は、レベル集計の列の名前と同じです(競合がチェックされます)。

      • ファクト表とレベル表は、この代理キーのみを使用して結合されます。

    • データベースでは次のようになります。

      • ファクト集計表も対応する代理キーを持ちます。

      • 移入を通じて利用可能な新機能を使用してデータを設定します。