| Oracle® Business Intelligence Applications管理者ガイド 11gリリース1 (11.1.1.8.1) E56354-01 |
|
 前 |
 次 |
この章では、Oracle BI Applicationsにおける複数言語のサポートについて説明します。
この章の内容は次のとおりです。
Oracle BI Applicationsでは、Oracle BI Enterprise Editionのダッシュボードとレポートで公開されるメタデータレベルのオブジェクト、およびユーザーの優先言語に翻訳されたレコードを表示する際に使用するデータに対して複数言語サポートを提供しています。
ベース言語およびインストール済のデータ・ウェアハウス言語の構成
Oracle BI Applicationsをインストールしたら、Oracle BI Applications Configuration Manager (Configuration Manager)を使用して、Oracle Business Analytics Warehouseでサポートする言語を構成します。まず1つのベース言語を構成する必要があります。その上で、任意の数のインストール済言語を構成できます。通常、データ・ウェアハウスに対して指定したベース言語は、ソース・システムのベース言語に一致する必要があります。データ・ウェアハウスに対して指定したインストール済言語は、ソース・システムにインストールされている言語に一致させる必要はありません。データ・ウェアハウスのインストール済言語は、ソース・システムと比較して、数を多くしたり少なくしたりすることができ、場合によってはまったく異なる言語を設定することも可能です。トランザクション・システムとデータ・ウェアハウス間で言語が一致する場合は、トランザクション・システムから対応するレコードが抽出されます。言語が一致しない場合は、擬似翻訳レコードが生成されます。
注意: 使用する言語のみをインストールするようにしてください。これは、言語を1つインストールするごとに、データ・ウェアハウスに格納されるレコードの数が大幅に増大し、データベース全体のパフォーマンスに影響する可能性があるためです。
データ・ウェアハウス言語の構成方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Applications構成ガイド』を参照してください。
翻訳表
翻訳表には、ドメイン翻訳表とディメンション翻訳表という2つのタイプがあります。ドメイン翻訳表は1つのみ存在し、1つのドメインに対して各サポート言語の翻訳値を1つ保持します。ディメンション翻訳表は、特定の1つのディメンションに関連付けられた拡張表であり、複数存在します。翻訳可能な属性の特定の特性に応じて、ドメインまたはディメンション翻訳表のいずれかに見つかります。
ユーザーのセッション言語は、USER_LANGUAGE_CODEという名前のOracle BI Enterprise Editionセッション変数で取得されます。これは、ユーザーの優先言語を選択するAnswersからユーザーがログインするときに設定されます。ユーザーがセッションの途中で優先言語を変更することを決定し、管理オプションを使用して現在の言語を変更すると、この変更がこのセッション変数によって検出されます。翻訳表から返されたレコードは、このセッション変数に一致するLANGUAGE_CODE値を持つレコードにフィルタ処理されます。
ETLプロセスは、データ・ウェアハウスにインストールされている言語に対応する翻訳レコードをソース・システムから抽出します。データ・ウェアハウスにインストールされている言語に対応するレコードがソース・システムに見つからない場合、擬似翻訳レコードが生成されます。擬似翻訳レコードがない場合、その欠落している言語を優先言語として使用してログインしているユーザーは、レコードを表示できません。
擬似翻訳レコードの生成は、データ・ウェアハウスのベース言語に対応する翻訳レコードをコピーし、そのコピーに対して欠落しているレコードの言語でフラグを設定することによって行われます。このフラグの設定は、LANGUAGE_CODE列に言語値を移入することによって行われます。SRC_LANGUAGE_CODEには、擬似翻訳レコードの生成元となった言語が格納されます。これにより、データ・ウェアハウスのベース言語に常に一致するようになります。
将来、ソース・システムで翻訳レコードが作成された場合、その翻訳レコードが抽出され、実際の翻訳値を反映するように擬似翻訳レコードが上書きされます。表2-1の例では、「US」がデータ・ウェアハウスのベース言語、「IT」と「SP」がインストール済言語になっています。ソース・システムには、「US」および「IT」に対する翻訳レコードしかなく、「SP」に対する翻訳レコードはありませんでした。「US」および「IT」のレコードは抽出され、データ・ウェアハウスにロードされます。ソース・システムには「SP」言語に対する翻訳レコードがないため、「US」レコードをコピーして、LANGUAGE_CODEでフラグを設定することにより、仮の「SP」レコードとして擬似翻訳レコードが生成されます。SRC_LANGUAGE_CODEは、ベース言語に一致するLANGUAGE_CODEと異なるので、擬似翻訳レコードを識別できます。
ドメインとは、リレーショナル・データベースの表の列の、使用可能な一意値のことを指しています。トランザクション・システムでは、ドメインはしばしば値リスト(list of values: LOVs)と呼ばれます。値リストは、ユーザーのセッション言語の属性選択を示します。トランザクションの格納はユーザーの言語と無関係です。そのため、フィールドは、言語に依存しない識別子を使用して格納されます。通常、この識別子は文字コードですが、数値のIDにすることもできます。この場合、LOVまたはドメインは、IDと値のペア(メンバーと呼ばれます)に基づいており、LOVはユーザーのセッション言語の値を示しています。実行時に、これらのIDは、ユーザーのセッション言語に対応する値に解決されます。
Oracle Business Analytics Warehouseでは、特定のドメイン内の一意値の数は比較的少なく、関連付けられているディメンションと比べて低いカーディナリティを持つ場合があります。たとえば、個人ディメンションには、ドメイン「性別」を関連付けることができます。ディメンションは何百万ものレコードを持つ可能性がありますが、ドメインは通常2つまたは3つのメンバー(M、F、場合によってはU)を持ちます。Oracle Business Analytics Warehouseでは、性別コードは個人ディメンションに格納され、翻訳値を格納するドメイン翻訳表に対する外部キーとしての役割を果たします。問合せが実行されると、コード値に関連付けられたユーザーフレンドリなテキストが、ユーザーのセッション言語で返されます。
ドメインに関連付けられた特定のプロパティに応じて、Configuration Managerでドメインを構成できます。翻訳をサポートするメカニズムとして機能するのに加え、ドメインを使用して、異なるソース・データを適合させ1つの共通のデータセットに統合できます。
データ・モデル
Oracle BI Applicationsのドメインは、%_CODE命名規則に従うディメンション表のフィールドとしてディメンションに関連付けられます。たとえば、個人ディメンションW_PARTY_PER_Dは、GENDER_CODE列に性別ドメインを格納します。
Oracle BI Applicationsのドメインは、ドメイン翻訳表W_DOMAIN_MEMBER_LKP_TLに格納されます。この表は、ドメイン・メンバー・コードごとに翻訳値を格納します。通常、翻訳値は名前または説明の値であり、これらの値は、この表のNAME列およびDESCR値に格納されます。DOMAIN_MEMBER_CODE列は、ディメンション表の%_CODE列と結合する際にキー列の役割を果たします。ドメインは様々なシステムから生じるので、翻訳値の発生元となるシステムを識別するためにDATASOURCE_NUM_ID列が使用され、ディメンション表との結合キーの一部として使用されます。翻訳値が関連付けられている言語を識別するために、LANGUAGE_CODE列が使用されます。LANGUAGE_CODE列は、%_CODE命名規則に従うことに注意してください。言語は、特定の一意値のセットを含むドメインと考えられます。
ETLプロセス
W_DOMAIN_MEMBER_LKP_TL表は、ソース・システムから抽出されたドメインおよびConfiguration Managerでシードされた内部定義ドメインの両方を格納します。ETLプロセスは、ソース・システムで利用可能な翻訳値を持つ%_CODE列ごとに、トランザクション・システムからドメイン・メンバーを抽出し、W_DOMAIN_MEMBER_LKP_TLにロードします。内部定義ドメイン(通常はOracle Business Analytics Warehouseに固有のドメインであり、適合ドメインと呼ばれるが、ソース・ドメインを含めることもできる)はConfiguration Managerスキーマに格納され、同様にETLプロセスを通して抽出されW_DOMAIN_MEMBER_LKP_TL表にロードされます。
データ・ウェアハウスにインストールされている言語のいずれかに一致する翻訳レコードのみが、トランザクション・システムから抽出されます。トランザクション・システム内にインストール済言語に一致する翻訳レコードが見つからない場合、ETLは、その言語に対して擬似翻訳レコードを生成します。
一部のソース・アプリケーションは、抽出して翻訳表にロードできる翻訳を格納します。一部のソース・アプリケーションは、ディメンション表に対応するエンティティに対する翻訳を維持しません。これらのケースでは、利用可能なレコードはみな抽出され、他のすべてのインストール済言語に対する擬似翻訳を生成するためにベース言語レコードとして使用されます。
図2-0は、Oracle BI ApplicationsドメインETLプロセスの概要を示しています。
Oracle BI ApplicationsのドメインおよびOracle BI Enterprise Editionについて
Oracle BI Enterprise Editionで翻訳値を取得するために使用される正確なメカニズムは、LOOKUP()関数です。LOOKUP()関数を使用する際、Oracle BI Enterprise Editionは、ルックアップ表に結合する前にすべての集計を実行します。その後、集計済の結果セットがルックアップ表に結合されます。低いカーディナリティの属性は、複数の集計に関わる傾向があるため、結果の集計前でなく集計後に結合する方が有益です。
論理ディメンションでは、名前属性または説明属性でLOOKUP()関数が使用され、その名前または説明に関連付けられた%_CODE列の値がドメイン・ルックアップ表に渡されます。LOOKUP()関数には、値をルックアップする際に使用するドメイン名が含まれます。ドメイン・ルックアップ表から得られた結果は、ユーザーのセッション言語に一致するようにフィルタ処理され、問合せ結果の一部として返されます。
ドメインは、ソースにしたり適合させることができます(内部定義ウェアハウス・ドメイン)。ソース・ドメインは様々なトランザクション・システムから生じる可能性があるため、解決するためのDatasource_Num_Id値を含める必要があります。適合ドメインはOracle BI Applicationsの一部として定義されるので、解決するためのDatasource_Num_IDは必要ありません。結果として、Oracle BI Repositoryに2つのルックアップ表が実装され、これらはW_DOMAIN_MEMBER_LKP_TLの別名になります。ソース・ドメインを解決する際、ソース・ドメインのルックアップでは、Datasource_Num_IdをLOOKUP()関数の一部として渡す必要がありますが、適合ドメインのルックアップの場合はその必要はありません。
第2.3項「Oracle BI Applicationsのドメインについて」で説明したように、ドメインは、比較的少ない数の区別が明瞭なメンバーを持つディメンション属性であり、ディメンションのレコードの数に比べて低いカーディナリティを持ち、しばしば集計で使用されます。ディメンションには、他に、これらの基準の1つ以上に合わない翻訳を必要とする属性があります。ディメンションが、ディメンションに比べて高いカーディナリティを持つ翻訳可能な属性を持っていたり、多数のメンバーを持っていたりすることがあり、この場合、集計候補になる可能性は低くなります。このようなケースでドメインETLプロセスが実装された場合、パフォーマンスが非常に低下します。結果として、これらの特定の属性は、ディメンション翻訳表を使用して実装されます。
データ・モデル
ディメンションが、ドメインとして扱うことができないこのような高いカーディナリティの属性を持つ場合、そのディメンションは、_TL命名規則に従う拡張表を持つことになります。_TL表が、(言語に対するフィルタ処理後に)ディメンション表と1対1の関係を持つ場合、_TL表の名前は、ディメンション表の名前に一致します。たとえば、W_JOB_D_TLは、W_JOB_Dディメンション表に関連付けられた翻訳表です。_TL表が、いかなるディメンション表とも1対1の関係を持たない場合、その名前は内容を反映します。
ディメンションとディメンション翻訳表は、翻訳表のINTEGRATION_ID + DATASOURCE_NUM_IDに基づいて結合されます。翻訳表とディメンション表が(言語に対するフィルタ処理後に)1対1の関係を持つ場合、ディメンション表との結合は、INTEGRATION_ID + DATASOURCE_NUM_IDに基づいて行われます。1対1の関係を持たない場合、翻訳表に結合するために使用されるディメンション表に%_ID列が用意されます。
ETLプロセス
Oracle BI ApplicationsドメインETLプロセスと同様に、ディメンション翻訳表を使用する際には、ETLのタスクによってトランザクション・システムから翻訳値が抽出されます。ドメイン・ステージング表をロードするかわりに、ディメンションの翻訳ステージング表がロードされます。その後、ETLプロセスでこれらのレコードをディメンション翻訳表に移動します。
データ・ウェアハウスにインストールされている言語のいずれかに一致する翻訳レコードのみが、トランザクション・システムから抽出されます。トランザクション・システム内にデータ・ウェアハウスのインストール済言語に一致する翻訳レコードが見つからない場合、ETLは、データ・ウェアハウスのベース言語に対応するレコードをコピーすることによって、その言語に対して擬似翻訳レコードを生成します。
一部のソース・アプリケーションは、抽出して翻訳表にロードできる翻訳を格納します。一部のソース・アプリケーションは、ディメンション表に対応するエンティティに対する翻訳を維持しません。これらのケースでは、利用可能なレコードはみな抽出され、ベース言語レコードとして使用されます。このレコードは、他のすべてのインストール済言語に対する擬似翻訳を生成するために使用されます。
Oracle BI Applicationsは、ディメンション表と翻訳表が互いに1対1の関係を持つ場合、ディメンション翻訳の属性に関するType 2 SCDのトラッキングをサポートしません。これらの表はINTEGRATION_ID + DATASOURCE_NUM_IDに基づいて結合されるので、翻訳表内の単一のレコードに結合できます。ディメンション表内の属性はType 2に対応可能ですが、現在および以前のレコードは常に同じ翻訳値を持ちます。図2-2は、ETLドメインプロセスを示しています。
Oracle BI Enterprise Edition
Oracle BI Enterprise Editionでは、ディメンション表と翻訳表の間の結合は通常どおり作成されます。翻訳表は、論理表ソースの別のサポート表として取り込まれます。ユーザーが翻訳表から属性を選択すると、その属性は、Oracle BI Enterprise Editionが生成するSQLの結合表として組み込まれます。ユーザーが翻訳属性を選択しない場合、翻訳表は、生成されたSQLに組み込まれません。
この動作を保証するために、ディメンション表と翻訳表の間の物理結合は、多様な側面におけるディメンション表との1対多関係として構成されます。
重要な検討事項は、ユーザーの言語に対してフィルタ処理を行います。コンテンツ・フィルタとして言語フィルタが論理表ソースに組み込まれている場合、ユーザーが翻訳属性を選択しているかどうかに関係なく、翻訳表は常に結合されます。この動作を回避するために、ユーザーのセッション言語に対して、WHERE句を含む物理レイヤーに不透明なビューが作成されます。ユーザーの言語に対するフィルタ処理は引き続き可能ですが、論理表ソース・コンテンツ・フィルタとしてフィルタ基準が実装されないため、翻訳表は必要な場合のみ結合されるようになります。
新しいドメイン・メンバーおよびOracle BI Repositoryメタデータのローカライズ
ローカライゼーションを必要とする新しいドメイン・メンバーを追加した場合は、『Oracle Fusion Middleware Oracle Business Intelligence Applications構成ガイド』の新しいドメイン・メンバーをローカライズする方法に関する項を参照してください。
また、Oracle BI Repositoryメタデータの文字列のローカライゼーションを追加する場合は、『Oracle Fusion Middleware Oracle Business Intelligence Applications構成ガイド』のOracle BI Repositoryメタデータの文字列のローカライゼーションを追加する方法に関する項を参照してください。
