| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 12c (12.2.1.1.0) E77226-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 12c (12.2.1.1.0) E77226-02 |
|
|
前へ |
次へ |
Oracle BIサーバーはいくつかの言語の翻訳をサポートしています。
この項では、複数の言語でフィールド情報を表示できるようにOracle BIサーバーを構成する方法について説明します。内容は次のとおりです。
管理ツールの使用の詳細は、Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイドを参照してください。
多言語データのサポートとは、データベース・スキーマのデータを複数の言語で表示する機能です。
Oracle BIサーバーは、翻訳の管理を簡素化し、その問合せパフォーマンスを改善することによって多言語スキーマをサポートします。多言語スキーマでは、通常、翻訳済フィールドが参照表と呼ばれる個別の表に格納されます。参照表には記述子列の翻訳が複数言語で格納され、ベース表にそのデータが元の言語で格納されます。記述子列は、キー列のテキストによる説明を提供します。記述子列とキー列の間には1対1の論理的関係があります。たとえば、記述子列はProduct_Nameなどで、これはProduct_Key列のテキストによる説明を提供します。
参照とは、問合せによってベース表と参照表を結合し、ベース表の各行に対して翻訳済の値を取得することを指します。
その性質上、参照表には「密」および「疎」があります。密である参照表には、ベース表のすべてのレコードの翻訳が、すべての言語で格納されています。疎である参照表には、ベース表の一部のレコードの翻訳のみが格納されています。場合によって、参照表は密および疎の両方であることがあります。たとえば、参照表に、Product Descriptionフィールドのすべての翻訳が含まれる一方、Product Categoryフィールドの一部の翻訳のみが含まれるような場合です。密および疎とは、表の性質というよりも、参照操作のタイプになります。参照表は、管理ツールを使用して構成します。
二重列サポートとは、論理レイヤーの2つの列(記述子ID列と記述子列)を関連付ける機能であり、言語非依存フィルタの定義に役立ちます。
ユーザーが記述子列に基づいてフィルタを作成すると、問合せツールにより、記述子列から選択された値のリストがユーザーに表示されます。
この記述子列の手法は、CLOBやBLOBなどのLOBデータ型に関連する問合せを処理する場合、およびCOUNTまたはSUMなどの集計関数を処理する場合にも便利です。一部のデータ・ソースでは、GROUP BY句でのLOB列の使用は許可されていません。したがって、LOB列をGROUP BYに追加するかわりに、LOB列との1対1の関係を持つ他の列でグループ化し、集計が行われた後にLOB列を結合する必要があります。
多言語スキーマで翻訳参照表を設計する一般的な手法には、次の2つがあります。
多くの場合、ベース表ごとに個別の参照表があります。参照表には、ベース表内のレコードへの外部参照キーが含まれ、各翻訳済フィールドの値が個別の列に含まれます。
参照表が完全に密である場合、特定言語用の参照表内の行数は、ベース表内の行数と等しくなります。
次の図の例は、ベース表内の1つの行のみに一致する、参照表内の各レコードを示しています。
この項では、論理参照表および論理参照列の作成について説明します。内容は次のとおりです。
ビジネス・モデルで論理参照表オブジェクトを作成して、翻訳参照表に必要なメタデータを定義します。
「論理表の参照表としての指定」で説明しているように、参照表とは、自身を参照表として指定するプロパティを持つ論理表のことです。次の図は、参照表の例を示しています。
参照表の各主キーをまとめて参照キーと見なし、参照が実行されます。参照は、すべての参照キー列に値が指定されている場合にのみ実行できます。たとえば、前述の図では、Product_CodeとLanguage_Keyの組合せによってこの参照表の主キーが形成されます。
参照キーは論理表キーとは異なります。参照キー列ではその順序が考慮されます。たとえば、Product_CodeとLanguage_Keyの参照キーは、Language_KeyとProduct_Codeの参照キーとは異なると見なされます。参照キー列の順序は管理ツールで指定できます。参照キーのすべての列は参照関数で結合する必要があります。
参照表には参照キーが1つのみ含まれます。
参照表には少なくとも1つの値列が含まれます。前述の図ではDescriptionが値列であり、製品の説明の翻訳済値が含まれています。
参照キーから各値列への関数従属性が存在する必要があります。言い換えれば、参照キーによって値列を識別できます。参照キーおよび値列は、どちらも同じ物理表に属している必要があります。
参照表は独立しており、他の論理表には結合されません。
整合性チェック・ルールは参照表に対しては緩和されているため、表が参照表として指定されている場合、サブジェクト・エリア内の他の表と結合する必要はありません(論理表は、通常、サブジェクト・エリア内の1つ以上の表に結合されます)。
参照列を使用した集計の結果は、ベース列を使用した結果と一致する必要があります。たとえば、次のコードを実行したとします
SELECT product.productname_trans, sales.revenue FROM snowflakesales;
これは、次のコードと同じ結果を戻す必要があります。
SELECT product.productname, sales.revenue FROM snowflakesales;
この例の参照表productname_transで参照キーProductIDおよびLANGUAGEを使用している場合、両方の問合せで同じ集計結果が戻されます。
参照キーにproductnameとは異なる集計レベルの列が含まれる場合は、問合せで変更が取得され、集計に反映されます。
論理表を参照表として使用するには、管理ツールを使用して、事前に論理表を参照表として指定する必要があります。
論理表を参照表として指定するには、管理ツールを使用して、最初に参照表を物理レイヤーにインポートし、それを「ビジネス・モデルとマッピング」レイヤー内にドロップします。次に、論理参照表ごとに、「論理表」ダイアログで「参照表」オプションを選択する必要があります。
参照表の主キーに指定されている列の順番により、LOOKUP関数の対応する引数の順番が決まります。
たとえば、参照表の主キーがRegionKey列、CityKey列およびLanguageKey列で構成される場合、LOOKUP関数の対応する引数を同じ順番で指定する必要があります。主キー列の順番を変更するには、管理ツールを使用します。
LOOKUP関数は通常、「ビジネス・モデルとマッピング」レイヤーで、翻訳済の論理表列の式として使用されます。
LOOKUP関数の構文は、次のようになります。
Lookup ::= LookUp([DENSE] value_column, expression_list ) | LookUp(SPARSE value_
column, base_column, expression_list )
expression_list ::= expr {, expression_list }
expr ::= logical_column | session_variable | literal
例:
LOOKUP( SPARSE SnowflakeSales.ProductName_TRANS.ProductName, SnowflakeSales.Product.ProductName, SnowflakeSales.Product.ProductID, VALUEOF(NQ_SESSION."LANGUAGE")) LOOKUP( DENSE SnowflakeSales.ProductName_TRANS.ProductName, SnowflakeSales.Product.ProductID, VALUEOF(NQ_SESSION."LANGUAGE"))
次の点に注意してください。
LOOKUP関数は密または疎のいずれかで、キーワードDENSEまたはSPARSEを使用して指定します。DENSEとSPARSEをどちらも指定しない場合、デフォルト動作は密参照になります。DENSE参照の場合、翻訳表は内部結合を通じてベース表に結合されますが、SPARSE参照の場合は左外部結合が実行されます。
第1パラメータ(DENSEまたはSPARSEキーワードの後のパラメータ)は、論理レイヤーで定義されている有効な参照表の有効な値列にする必要があります。
SPARSEキーワードを指定した場合、第2パラメータは、value_columnのベース値を提供する列にする必要があります。DENSE参照の場合、このベース列は必要ありません。
expression_listの式の数は、value_columnで定義した、参照表で定義されている参照キー列の数と同じにする必要があります。また、式リストで指定した式は、参照キー列と1対1で順番に一致している必要があります。
例:
参照表ProductName_TRANSの参照キーは、Product_codeおよびLanguage_Keyの両方です。
expression_listの式は、SnowflakeSales.Product.ProductIDおよびVALUEOF(NQ_SESSION."LANGUAGE")です。
この参照の意味を次に示します。
Product_code = SnowflakeSales.Product.ProductIDおよびLanguage_Key = VALUEOF(NQ_SESSION."LANGUAGE")という条件を使用して、翻訳表からProductNameの翻訳済の値を戻します。
参照関数を含む論理列を作成するには、管理ツールで式ビルダーを使用します。
論理列の値は、現在のユーザーに関連付けられている言語に基づきます。
たとえば、翻訳済の製品名を取得するには、「列ソース」タブで、導出された列式を使用して新しい論理列を作成します。
LAN_INTはセッション初期化ブロックMLSにより移入されるセッション変数で、基本言語または他の言語を表します。
基本言語(たとえば、en - English)の場合は0
他の言語コード(たとえば、fr - Frenchまたはcn - Chinese)の場合は1
WEBLANGUAGEは、ユーザーがログイン時に選択した言語に基づいて自動的に初期化されるセッション変数です。
INDEXCOL関数は、適切な列の選択をサポートします。前述の例では、ユーザー言語が基本言語の場合(つまり、セッション変数LAN_INTの値が0の場合)にのみ、基本列(ProductName)の値が戻されます。ユーザー言語が基本言語でない場合(セッション変数LAN_INTの値が1の場合)は、WEBLANGUAGEセッション変数に渡された言語の参照表から値が戻されます。
(前述の例の)DENSE関数を使用する場合、翻訳対象言語の列に値がないと、参照関数により空白のエントリが表示されます。
(次の例の)SPARSE関数を使用する場合、翻訳対象言語の列に値がないと、参照関数により基本言語で対応する値が表示されます。
INDEXCOL( VALUEOF(NQ_SESSION."LAN_INT"), "Translated Lookup Tables"."Product". "ProductName", LOOKUP( SPARSE "Translated Lookup Tables"."Product Translations". "ProductName", "Translated Lookup Tables"."Product"."ProductName", "Translated Lookup Tables"."Product"."ProductID", VALUEOF(NQ_SESSION."WEBLANGUAGE")))
派生論理列を使用する場合は、エラーを減らすための計画が必要となります。
派生論理列を使用する場合は、次のヒントに留意してください。
LOOKUP関数の結果として導出された論理列を、主論理キーとして使用することはできません。この制限が存在する理由は、LOOKUPの操作は集計が計算された後に適用されますが、レベル・キー列は集計が計算される前に利用可能である必要があるためです(レベル・キー列は集計計算の粒度を定義するため)。
LOOKUP関数の結果として導出された論理列は、2次論理レベル・キーとして使用できます。
導出した式に参照関数が含まれる派生論理列については、次の点に留意してください。
参照関数で使用される論理列に関連付けられたレベルは、派生論理列自体のレベルよりも低くしないでください。
推奨される方法は、記述子ID列を構成することです。
表内のデータに非ISOタイプの言語コードが含まれる場合は、ISO言語コードを非ISO言語コードにマップする表が必要になります。
ユーザーのログイン時にISO言語コードを設定する既存のWEBLANGUAGE変数を使用できます。個別のLANGUAGE変数を定義し、その初期化ブロックでマッピング表に対して問合せを実行して、WEBLANGUAGE変数の値でフィルタされた非ISO言語コードをフェッチします。次の表に、非ISO言語コードのマッピング表を示します。LANGUAGEが非ISO言語コードです。
| WEBLANGUAGE | LANGUAGE | LAN_INT |
|---|---|---|
en |
ENG |
0 |
cn |
CHI |
1 |
fr |
FRA |
1 |
ビジネス・モデルで物理参照表オブジェクトを作成して、翻訳参照表に必要なメタデータを定義できます。物理参照表は、その意味と使用方法の両方において論理参照表に類似しています。
物理参照表は、論理参照表で処理できない次のシナリオに対処します。
参照表ソースが断片化されている。この場合、複数の物理参照表を使用して値を保持します。たとえば、断片化されている製品名データの翻訳値を、productname_trans_AtoMおよびproductname_trans_NtoZという2つの物理参照表に分散させることができます。
異なるレベルの翻訳表を使用できる。たとえば、Essbaseデータ・ソースとリレーショナル・データ・ソースの両方で翻訳を使用できます。基本問合せと同じソースを使用することをお薦めします。
論理参照表は「論理表」ダイアログでオプションを選択することにより指定しますが、物理参照表は論理表ソース・マッピングで参照関数を作成することにより構成します。
たとえば、次の物理表があるとします。
categoryidおよびcategorynameなどの列を含む、Categoriesという名前のベース表。
categoryid、language_keyおよびcategorynameなどの列を含む、Categories_Transという名前の翻訳表。categorynameの翻訳済値は、categoryid列およびlanguage_key列の組合せにより決定されます。
Categoriesという名前の論理表があるとします。この表に、categoryname_pという名前の新しい論理列を追加します。この列は、現在の言語に基づく翻訳列です。論理参照列とは異なり、この列は他の論理列からは導出されません。
次の手順で、前述の例を使用して、物理参照翻訳列を構成する方法について説明します。
物理参照表から導出される翻訳列を構成するには:
Categories_trans物理翻訳表を論理表ソースに組み込む必要はありません。INDEXCOL関数により、LAN_INTセッション変数が0であるかどうかチェックされ、ベース表からcategoryname列がフェッチされます。LOOKUP関数について次の点に注意してください。
物理LOOKUP関数は論理LOOKUP関数と同様に機能します。唯一の違いは、論理表および論理列に対するすべての参照が、物理表および物理列に置き換えられることです。
LOOKUP関数の第1列は値列で、これは翻訳表の翻訳値列です。疎参照が存在する場合、第2列は基本値列です。残りの列は、物理翻訳表に結合される列または値です。この物理翻訳表は、LOOKUP関数の値列により示されます。
ダイアログを使用して物理参照表を構成できないため、結合列および値の順番と、物理翻訳表の「物理表」ダイアログに表示される列の順序に互換性があることを確認する必要があります。たとえば、Categories_trans表の「物理表」ダイアログの「Keys」タブでは、主キーはCategoryID列とLanguage_Key列により構成されます。
LOOKUP関数で指定される列は、次のように対応します。
次の行があるとします。
"DB_Name"."My_Category"."My_Schema"."Categories"."CategoryID"
これはCategories_trans.CategoryID列に対応します。
次の行があるとします。
valueof(NQ_SESSION."LANGUAGE")
これはCategories_trans.Language_key列に対応します。
LAN_INTセッション変数やLANGUAGEセッション変数などの参照の概念の詳細、およびLOOKUP関数の完全な構文の情報は、「論理参照表および論理参照列の作成」を参照してください。
多くの場合、Essbaseキューブのメンバーは、ユーザー言語ごとに個別の別名を用意して、ユーザーが自分の言語でメンバー名を表示できるようにします。
通常、セッション変数を定義して、ユーザーのログイン時に適切な別名を動的に選択します。Essbaseの別名表について、およびそれらをセッション変数で使用する方法の詳細は、Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイドを参照してください。
辞書編集上の差異によるソートは、データをアルファベット順にソートする機能です。
ほとんどのデータ・ソースは辞書編集上の差異によるソートをサポートしています。ただし、辞書編集上の差異によるソートが特定のデータ・ソースに対して適切に動作しない場合、Oracle BIサーバーを構成して、バックエンド・データ・ソース以外でソートを実行できます。この構成を実行するには、管理ツールの「データベース」ダイアログの「機能」タブで、ORDERBY_SUPPORTEDが選択解除されていることを確認します。データベース機能の指定の詳細は、Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイドを参照してください。
データ・ソースでORDERBY_SUPPORTEDを無効にすると、パフォーマンスに非常に大きな影響を与える場合があるので注意してください。これは、無効にした結果、多数の結合がデータ・ソースにプッシュダウンされないためです。多くの場合、パフォーマンスへの影響は非常に大きいため、辞書編集上の差異によるソート機能への影響に関係なく、ORDERBY_SUPPORTEDはデータ・ソースで有効にしておくことができます。
