| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 11g リリース1(11.1.1) B63029-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド 11g リリース1(11.1.1) B63029-01 |
|
前 |
次 |
ユーザーは言語およびロケールのプリファレンスを簡単かつ動的に変更できます。ユーザーが言語を選択すると、その言語で多くの要素が表示されます。これらの要素には、ユーザー・インタフェース・コンポーネント、メタデータ、メッセージおよびヘルプ・ファイルが含まれます。
この章では、英語以外の1つ以上の言語環境でデプロイメントを構成する方法について説明します。この章の内容は次のとおりです。
この章において、ローカライズとは、Oracle Business Intelligenceのデプロイメントを特定の言語に対応させるプロセスを指します。ユーザーが英語以外の言語を話す場合は、この章の情報を使用して、複数言語をサポートするようにデプロイメントを構成します。
サポートされる言語の詳細は、第1.8項「システム要件と認証」を参照してください。
英語以外の言語に翻訳されているOracle Business Intelligenceのコンポーネントを次に示します。
インストーラ
Webユーザー・インタフェース
Oracle BI Schedulerのジョブ・マネージャ・インタフェース
Catalog Manager
Oracle BI Presentation Servicesのメッセージ:
エラー
警告
情報
Oracle BI Serverの関数:
DayName
MonthName
|
注意: DayName関数またはMonthName関数を使用して問合せを発行しても、その関数がバックエンド・データベースに転送されない場合、日または月の名前はローカライズされた言語で戻されますが、列名は英語のままになります(または他のローカライズ制御の影響を受ける場合があります)。この例として、LOCALEパラメータがGermanに設定されている場合のMonthName問合せでは、文字列Maiが戻されますが、列ヘッダーはName of Monthのままです。 |
Oracle BI ServerおよびOracle BI Schedulerのメッセージ:
エラー
警告
情報
ログ・ファイル:
Oracle BI Serverのnqserver.log
Oracle BI Serverのnqquery.log
Oracle BI Server ClusterのnQCluster.log(クラスタリングが有効な場合)
メタデータ:
ダッシュボードおよび分析(Oracle BI Presentation Catalog)
プレゼンテーションの表および列の名前(.rpdファイル)
Oracle BI管理ツールのインタフェース
ODBCの設定
次のリストは、ローカライズされていないOracle Business Intelligenceのコンポーネントを示しています。
ODBCクライアント・ツール:
nqcmd (UNIX)
nQCmd.exe (Windows)
nQClient.exe (Windows)
Oracle WebLogic Server管理コンソールやFusion Middleware Controlなど、数多くのOracle Fusion Middlewareコンポーネントが翻訳されています。詳細は、Oracle Fusion Middlewareのドキュメントを参照してください。
次の各項の説明に従い、管理者として、Oracle Business Intelligenceのコンポーネントをローカライズするための各種タスクを実行します。
次の各項の説明に従い、管理者として、Oracle BI Presentation Servicesをローカライズするための各種タスクを実行します。
ユーザーが英語以外の言語を話す場合、Oracle BI Presentation Servicesのユーザー・インタフェースをローカライズできます。ユーザーは、Oracle BI EEのサインイン・ページで言語を選択できます。これにより、ユーザー・インタフェースの多くの要素が選択した言語で自動的に表示されます。サインイン後、ユーザーは、「マイ・アカウント」ダイアログの「プリファレンス」タブで言語設定を変更できます。
ユーザーの設定はWEBLANGUAGEセッション変数に保存されます。Oracle BI Presentation Servicesのユーザー・インタフェースでは、ユーザーがサインイン・ページで言語を選択したときにWEBLANGUAGEが設定されます。
|
注意: Oracle BIアプリケーションでは、ユーザーの初回ログイン時にWEBLANGUAGEがブラウザの言語に設定されます。たとえば、言語がフランス語に設定されているブラウザを使用してOracle BIアプリケーションに初めてログインすると、WEBLANGUAGEの値はFrenchになり、メタデータはフランス語に翻訳されます。 |
次の各項の説明に従い、管理者として、Oracle BI Presentation Servicesのユーザー・インタフェースの他の要素をローカライズするための各種タスクを実行します。
Oracle BI EEは、ユーザー・インタフェースの各要素およびメッセージを制御する多くのファイルとともにインストールされます。これらのファイルは、ORACLE_HOME\bifoundation\web\MS-DOSディレクトリのmessagesサブディレクトリおよびpagesサブディレクトリにインストールされます。これらの要素およびメッセージをローカライズするには、インストールされたファイルをORACLE_INSTANCE\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obipsn\msgdbサブディレクトリのl_xxサブディレクトリにコピーします(xxは言語拡張子を表します)。ファイルをコピーしたら、コピー先のサブディレクトリに対応する言語に合せてコンテンツを変更できます。
第16.2.1項「静的マッピングを使用したユーザーの優先通貨オプションの定義」では、ユーザーの優先通貨を使用する手順について説明しています。優先通貨に関連付けられたメッセージをローカライズするには、次の手順を使用します。
各ユーザーの優先通貨に関連付けられたメッセージをローカライズするには:
ORACLE_INSTANCE\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obipsn\msgdb\l_xxディレクトリに移動します。xxは、優先通貨を指定する言語の言語拡張子です。
このディレクトリで、custommessagesという名前のサブディレクトリを作成します。
このディレクトリで、usercurrencymessages.xmlという名前のXML形式のファイルを作成します。
作業しているディレクトリに対応する言語用のこのファイルに、次のようなエントリを追加します。次の例には、kmsgMyCurrency1およびkmsgMyCurrency2という2つのメッセージが含まれています。
<?xml version="1.0" encoding="utf-8"?> <WebMessageTables xmlns:sawm="com.siebel.analytics.web/message/v1"> <WebMessageTable system="CurrencyDisplay" table="Messages" code="false"> <WebMessage name="kmsgMyCurrency1"><TEXT>My Currency Text 1</TEXT></WebMessage> <WebMessage name="kmsgMyCurrency2"><TEXT>My Currency Text 2</TEXT></WebMessage> </WebMessageTable> </WebMessageTables>
このメッセージを使用するために、userpref_currencies.xmlファイルを編集してdisplayMessage="kmsgMyCurrency1"と指定します。
これらのメッセージをローカライズする各言語に対して、ステップ1 - 5を繰り返します。
Oracle BI Presentation Servicesのサービスを再起動します。
Oracle BI EEで、適切にローカライズされたテキストがユーザーに表示されます。この例では、表示されるテキストはMy Currency Text 1です。
プレゼンテーション・サービスのサインイン・ページの表示に使用されるデフォルト言語は、ユーザーのクライアント・ブラウザの設定から取得されます。次の手順は、この言語を変更する方法について説明しています。
|
注意: 次の手順では、例としてInternet Explorer 7.0を使用しています。別のブラウザを使用する場合は、必要に応じて内容を置き換えてください。 |
Internet Explorerでユーザーのログイン画面のデフォルト言語を変更するには:
Internet Explorerで、「ツール」メニューから「インターネット オプション」を選択します。
「インターネット オプション」ダイアログが表示されます。
「言語」をクリックします。
「言語の優先順位」ダイアログが表示されます。
インストールされている言語が「言語」リストに表示されます。リストの最上部にある言語がデフォルト言語として使用されます。
目的の言語がブラウザにインストールされていない場合は追加します。
「上へ」ボタンおよび「下へ」ボタンを使用して、目的の言語をリストの最上部に移動します。
ブラウザを再起動し、プレゼンテーション・サービスにサインインします。
デフォルト言語が、ブラウザの言語リストの言語と一致します。
|
注意: ユーザーがサインイン・ページのリストからデフォルト言語を選択しない場合は、ユーザーの「マイ・アカウント」ダイアログの「ユーザー・インタフェース言語」の設定によってユーザー・インタフェースの表示に使用される言語が決定されます。 |
サインイン・ページでユーザーが使用できる言語およびロケールを構成できます。この機能は、ユーザーがアクセスできる言語およびロケールの数を制限する場合に便利です。instanceconfig.xmlファイルのAllowedLanguages要素およびAllowedLocales要素によって、使用できる言語およびロケールを指定します。
第3.6項「構成ファイルの格納場所」の説明に従って、instanceconfig.xmlファイルを編集するために開きます。
ServerInstanceセクションを見つけます。ここで、次の要素を追加する必要があります。
AllowedLanguages: 選択できる言語を、カンマ区切りリストとして指定します。次の識別子(ISO 639言語コード)のリストを指定できます。
ar es da de el en es fi fr he hr hu it ja ko nl no pl pt pt-BR ro ru sk sv th tr zh-CN zh-TW
AllowedLocales: 選択できるロケールを、カンマ区切りリストとして指定します。ORACLE_HOME/bifoundation/web/displayディレクトリにあるlocaleDefinitions.xmlファイル内の任意の定義を指定できます。ロケールは、ISO 639言語コードの後ろにISO 3166国コードを記述して指定します(たとえば、fr-fr、fr-ca)。
次の例に示すように、必要な要素とその祖先要素を追加します。
<ServerInstance>
<Localization>
<AllowedLanguages>en,fr,pt-BR</AllowedLanguages>
<AllowedLocales>en-ca,en-us</AllowedLocales>
</Localization>
</ServerInstance>
変更内容を保存し、ファイルを閉じます。
Oracle Business Intelligenceを再起動します。
ユーザーは、サインイン・ページを表示してOracle BI EEを起動するとき、サインイン・プロセスの一部として言語を選択できます。また、「マイ・アカウント」ダイアログの「プリファレンス」タブで言語を選択することもできます。
ダッシュボードまたはアプリケーションの他のページを表示するURLをユーザーに提供する場合、URLパラメータをプロファイル属性として定義できます。これにより、アプリケーションの言語設定と一致するように、ダッシュボードおよび分析の言語が動的に設定されます。
運用アプリケーションでは、シンボリックURLによって統合環境内のダッシュボードおよび分析が組み込まれます。Oracle BI Presentation Servicesの場合、URLパラメータLangによってWebページのレンダリングで使用される言語が指定されます。
Langパラメータは、Oracle Business Intelligenceに接続する運用アプリケーションで定義されたシンボリックURLに含めることができます。Langパラメータはプロファイル属性として定義されますが、シンボリックURLが実行時に作成される場合は、プロファイル属性のLanguageCodeが値として設定されます。表15-1に、Langを含む、シンボリックURLパラメータ・アプレットのパラメータ設定の例を示します。
たとえば次のURLでは、サインイン・ページがフランス語で表示されます。
http://Server_Name:port_number/analytics/saw.dll?Dashboard&Lang=fr
Oracle BI Presentation Catalogには、分析およびダッシュボードなど、ユーザーが作成するオブジェクトが格納されます。これらのオブジェクトの名前および説明はテキスト文字列に保持されます。オブジェクトのテキスト文字列をローカライズする必要がある場合は、翻訳するために、カタログからテキスト文字列をエクスポートします。その後、文字列を翻訳して公開します。
この項では、キャプションをローカライズする手順について説明します。
エクスポート・プロセスでは、共有フォルダ内の第1レベルのサブフォルダそれぞれに対してXMLファイルが1つ作成されます。このファイル名の形式はfoldernamecaptions.xmlで、foldernameは共有フォルダ内のサブフォルダの名前を表します。各XMLファイルには、対応する第1レベル・フォルダおよびそのサブフォルダ内にあるすべてのコンテンツのテキスト文字列が含まれます。
たとえば、Oracle BI Presentation Catalogの共有フォルダにMarketing、ServiceおよびSalesという第1レベル・フォルダが含まれている場合は、エクスポート・プロセスによって次の3つのXMLファイルが作成されます。
marketingcaptions.xml
salescaptions.xml
servicecaptions.xml
コンテンツを翻訳した後、これらのフォルダを次のディレクトリ内の対応する場所に配置します。
ORACLE_INSTANCE\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obipsn\msgdb\l_xx\captions
エクスポート・プロセスでは、新しいXMLファイルが生成されるだけでなく、カタログが変更され、各オブジェクトの適切なメッセージIDが挿入されます。プレゼンテーション・サービスでは、これらのメッセージIDによって新しい翻訳済テキストが特定されます。
次の手順は、カタログ内のテキスト文字列をエクスポートする方法について説明しています。
エクスポートする前に、カタログをバックアップします。
エクスポート・ユーティリティは、カタログのコピーではなく、実際のカタログに対して実行する必要があります。これは、エクスポート・ユーティリティにより、実行対象のカタログ内のオブジェクトのプロパティが変更されるためです。
Catalog Managerで、カタログをオフライン・モードで開きます。これは、オンライン・モードでは、すべてのオブジェクトを変更するための権限がない可能性があるためです。
エクスポートする文字列を含むフォルダを選択します。ユーティリティは、対象フォルダ内、およびそのすべてのサブフォルダ内のファイルに対して実行されます。
たとえば、図15-1に示す分析のタイトル(Another Report)をエクスポートして翻訳できます。
「ツール」メニューから「キャプションのエクスポート」を選択します。
「参照」をクリックして、出力ファイルを書き込む場所を選択し、「OK」をクリックします。
新しいテキスト文字列と前回のエクスポート以降に変更されたテキスト文字列のみをエクスポートするには、「新規または変更済の文字列のみエクスポート」を選択します。
エクスポートから説明プロパティを除外するには、「説明の除外」を選択します。
「OK」をクリックします。
エクスポート・プロセスは数分かかる場合があります。
エクスポート・プロセスが完了したら、出力XMLファイルをローカライズ・チームに配信します。
XMLファイルを編集する場合は、XMLファイル用に設計されたエディタを使用します。XMLファイルの上部に指定されているエンコーディングに従うこと、および必要に応じて特殊文字をエスケープすることに注意してください。管理者およびローカライズ・チームのスタッフが、翻訳済テキスト文字列に関するエラーを解決する責任者です。オブジェクトが追加、削除または変更された場合は、常に、カタログのコンテンツが最新であることを確認します。
翻訳対象言語ごとに、すべての出力ファイルのコピーを作成できます。
図15-2は、エクスポートされたキャプションXMLファイルの翻訳前の抜粋です。ファイル名はmyfoldercaptions.xmlです。図15-3は、翻訳後のファイルの抜粋を示しています。ファイル名はmyfoldercaptions_fr.xmlです。
カタログからエクスポートしたテキスト文字列が重複する問題が発生することがあります。この状況は、複数のユーザーが「キャプションのエクスポート」ユーティリティを同時に実行した場合、または同じユーザーが1分以内にこのユーティリティを2回実行した場合に発生します。次の手順は、重複するキャプションに対処する方法について説明しています。
重複するエクスポートされたテキスト文字列を処理するには:
第15.2.2.2項 「ステップ2: カタログ内のテキスト文字列のエクスポート」の説明に従い、「キャプションのエクスポート」ユーティリティを実行します。
Catalog Managerで、カタログをオフライン・モードで開いたまま、エクスポートする文字列を含むフォルダを選択します。
「ツール」メニューから「キャプションのエクスポート」を選択します。
「参照」をクリックして、出力ファイルを書き込む場所を選択し、「OK」をクリックします。
「重複するキャプションの処理方法」セクションで、次のいずれかのオプションを選択します。
1つ残す: 重複するキャプションをそのまま残すことを指定します。
IDの削除: 重複するIDまたは無効なIDを含む任意のオブジェクトに対して、新しい一意のIDを生成することを指定します。
テキストの削除: 無効なIDを含む任意のオブジェクトに対して新しい一意のIDを生成すること、および有効であるけれども重複するIDを含むオブジェクトのテキスト文字列を削除することを指定します。
このオプションでは、同じ名前を持つ2つのオブジェクトがカタログのディレクトリ・リストに格納されます。これは、それぞれに一意の名前とメッセージIDを持つけれども、グラフの軸や凡例など、複数のコンポーネントで同じテキスト文字列を共有するような一連の分析に最も有効です。この場合、コンポーネントを翻訳する必要があるのは1回のみです。たとえば、「X Axis」を1回翻訳すれば、グラフごとに翻訳する必要はありません。
「OK」をクリックします。
重複するキャプションを含む、次のwebmessages.xmlファイルを考えてみます。
<WebMessageTable system="catalog" type="folder" path="/shared/example/A">
<WebMessage name="kcap12790830_5" use="Caption" status="new">
<TEXT>A Really Good Report</TEXT>
</WebMessage>
</WebMessageTable>
<WebMessageTable system="catalog" type="folder" path="/shared/example/B">
<WebMessage name="kcap12790830_5" use="Caption" status="new">
<TEXT>I like this report</TEXT>
</WebMessage>
</WebMessageTable>
<WebMessageTable system="catalog" type="folder" path="/shared/example/Copy of A">
<WebMessage name="kcap12790830_5" use="Caption" status="new">
<TEXT>A Really Good Report</TEXT>
</WebMessage>
</WebMessageTable>
このサンプル・ファイルでは、オブジェクトBが無効な重複するメッセージIDを持ち、オブジェクトCopy of Aが有効であるけれども重複するメッセージIDを持っています。「キャプションのエクスポート」ダイアログで、次のいずれかを選択します。
「1つ残す」を選択すると、ファイルのコンテンツは変更されません。
「IDの削除」を選択すると、オブジェクトBおよびオブジェクトCopy of Aの両方に対して新しい一意のIDが生成されます。
「テキストの削除」を選択すると、オブジェクトBに対して新しい一意のIDが生成され、オブジェクトCopy of AのWebMessage要素が削除されます。このオプションにより、通常、翻訳するメッセージは少なくなりますが、プレゼンテーション・サービスおよびCatalog Managerのカタログのディレクトリ・リストで、同じ名前を持つ2つのオブジェクトが表示されることに注意してください。
カタログのテキスト文字列をエクスポートしたら、それをユーザーに公開する必要があります。
翻訳済のXMLファイルを次のディレクトリ内の対応する場所に配置して、プレゼンテーション・サービスを再起動します。
ORACLE_INSTANCE\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obipsn\msgdb\l_xx\captions
xxは言語拡張子です。
例:
D:\R11\instances\instance1\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obips1\msgdb\l_fr\captions\myfoldercaptions_fr.xml
言語拡張子には、チェコ語を表すcs、ドイツ語を表すdeなどがあります。
|
注意: ORACLE_INSTANCE\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obipsn\msgdb\l_xx\captionsディレクトリは、Oracle Business Intelligenceアプリケーションがインストールされている場合にのみ存在します。このディレクトリが存在しない場合は作成する必要があります。 |
エクスポート・プロセスでは、新しいXMLファイルが生成されただけでなく、カタログが変更され、各オブジェクトの適切なメッセージIDが挿入されました。ステップ1の指示に従って翻訳済のXMLファイルをディレクトリに配置したら、変更済のカタログを、そのデフォルトの場所に配置するか、システムが現在使用している適切な場所に配置します。詳細は、第10.2項「リポジトリをアップロードしOracle BI Presentation Catalogの場所を設定するためのFusion Middleware Controlの使用」を参照してください。
Oracle Business Intelligenceにサインインして、フランス語など、適切な言語を選択します。
翻訳済のコンテンツを表示します。
たとえば、図15-4に示すように、分析の翻訳済のタイトルを表示します。
翻訳済のキャプションを開発環境から本番環境に移動するには:
キャプション・ファイルの処理:
キャプション・ファイルが本番環境に存在しない場合は、開発環境から本番環境へ単純にファイルをコピーします。
キャプション・ファイルが本番環境に存在する場合は、最初に既存ファイルのバックアップ・コピーを作成します。次に、テキスト・エディタまたはXML編集ツールを使用して本番環境のキャプション・ファイルを開き、開発環境で行った変更を手動で(十分に注意しながら)挿入します。
デフォルトでは、スクロール・バーはMozilla Firefoxブラウザの右側に表示されます。アラビア語またはヘブライ語を使用する場合、右側にスクロール・バーが表示されるのは適切ではありません。スクロール・バーが左側に表示されるように、Firefoxでブラウザ設定を変更できます。
layout.scrollbar.side設定の変更の詳細は、Firefoxのドキュメントを参照してください。
Catalog Managerを使用する場合、そのユーザー・インタフェース要素に使用するロケール、およびカタログ内のオブジェクトに使用するロケールを指定できます。これらのロケールは、同じでも異なっていても構いません。ユーザー・インタフェース要素には10のロケールを使用でき、特定アプリケーションのカタログ・コンテンツには28のロケールを使用できます。
Catalog Managerのユーザー・インタフェース要素(ダイアログ、メニューなど)は、使用可能な10のロケールのいずれかで表示できます。データ処理などのCatalog Managerの特定の領域は、現時点では翻訳またはローカライズされていません。Catalog Managerでは、次のプロセスで、表示するロケールが決定されます。
Catalog Managerが起動されたら、-nl <locale>パラメータの設定をチェックします。このパラメータは、次の例に示すように、runcat.cmdまたはruncat.shファイルのCATMAN_VMARGS変数の一部としてユーザーが設定します。
set CATMAN_VMARGS=-nl fr -vmargs -Xmx1024M -Dosgi.clean=true
set CATMAN_VMARGS=-nl fr_CA -vmargs -Xmx1024M -Dosgi.clean=true
コンピュータに指定された、Javaのデフォルト・ロケールをチェックします。
デフォルト・ロケールの英語(厳密にはen_US)を使用します。
Catalog Managerを起動してカタログをオンライン・モードで開くと、そのコンテンツを表示するためのロケールを選択できます。選択可能なロケールは次の条件により決まります。Catalog Managerでは、以降のオンライン接続に、この選択したロケールが使用されます。
インストール・プロセスでプレゼンテーション・サービス用にロケールが選択されているかどうか。
カタログのコンテンツが特定のロケールで翻訳されているかどうか。
ロケールの翻訳済ファイルがない場合、コンテンツはデフォルト・ロケールの英語(厳密にはen_US)で表示されます。
Catalog Managerの詳細は、第17.3項「カタログ・マネージャについて」を参照してください。
次の各項では、Oracle BI Serverでのロケールの設定について説明します。
複数言語をサポートするには、Oracle BI Serverを適切に構成する必要があります。NQSConfig.INIファイルのGeneralセクションには、ローカライズおよび国際化に必要なパラメータが含まれています。また、Oracle BI Serverからクライアント・アプリケーションへのデータの送信方法を決定するデフォルト・パラメータも含まれています。これらのパラメータの詳細は、付録A「NQSConfig.INIファイルの構成設定」を参照してください。
NQSConfig.INIファイル内のローカライズに影響するパラメータは次のとおりです。
LOCALE
SORT_ORDER_LOCALE
SORT_TYPE
CASE_SENSITIVE_CHARACTER_COMPARISON
Oracle Business Intelligenceを正常に実行するには、ユーザーがアプリケーションを実行する言語について、オペレーティング・システムのロケールを適切に構成する必要があります。ロケールおよび言語に関する一部の設定は相互に関連しており、Oracle BI Serverでのデータのソート方法の決定に役立ちます。
サーバー起動時にC-run-timeロケールに対して使用される値は、NQSConfig.INIファイルのSORT_ORDER_LOCALEパラメータに指定されています。このパラメータは、通常、Oracle BI Serverにより設定されます。このロケールは、日付や通貨の表示、およびデータのソートなどの機能で使用されます。
設定を調整する必要がある場合は、NQSConfig.INIファイルのGeneralセクションで、表15-2に示すプラットフォーム非依存の名前を入力してLOCALEパラメータおよびSORT_ORDER_LOCALEパラメータを設定します。
表15-2に、プラットフォーム非依存の名前と、サポートされる各UNIXプラットフォーム固有の名前の言語マッピングを示します。たとえば、HP-UXまたはLinuxオペレーティング・システムでは、中国語にzh_CN.utf8設定が使用されます。
zh_CN.utf8やfr-FR-UTF-8などの名前文字列はプラットフォーム固有のロケール・コンポーネントの名前であり、システム管理者がインストールする必要があります。NQSConfig.INIファイルでは、ChineseやFrench(大文字小文字は区別されません)など、プラットフォーム非依存の名前が使用されます。
15-2 UNIXプラットフォームのLOCALE設定
| ロケール(プラットフォーム非依存の名前) | Solarisでの名前 | AIXでの名前 | HP-UX/Linuxでの名前 |
|---|---|---|---|
|
Arabic |
ar_SA.UTF-8 |
AR_AA.UTF-8 |
ar_SA.utf8 |
|
Chinese |
zh_CN.UTF-8 |
ZH_CN.UTF-8 |
zh_CN.utf8 |
|
Chinese-traditional |
zh_TW.UTF-8 |
ZH_TW.UTF-8 |
zh_TW.utf8 |
|
Croatian |
hr_HR.UTF-8 |
HR_HR.UTF-8 |
hr_HR.utf8 |
|
Czech |
cs_CZ.UTF-8 |
CS_CZ.UTF-8 |
cs_CZ.utf8 |
|
Danish |
da_DK.UTF-8 |
DA_DK.UTF-8 |
da_DK.utf8 |
|
Dutch |
nl_NL.UTF-8 |
NL_NL.UTF-8 |
nl_NL.utf8 |
|
English-USA |
en_US.UTF-8 |
EN_US.UTF-8 |
en_US.utf8 |
|
Finnish |
fi_FI.UTF-8 |
FI_FI.UTF-8 |
fi_FI.utf8 |
|
French |
fr_FR.UTF-8 |
FR_FR.UTF-8 |
fr_FR.utf8 |
|
German |
de_DE.UTF-8 |
DE_DE.UTF-8 |
de_DE.utf8 |
|
Greek |
el_GR.UTF-8 |
EL_GR.UTF-8 |
el_GR.utf8 |
|
Hebrew |
he_IL.UTF-8 |
HE_IL.UTF-8 |
iw_IL.utf8 |
|
Hungarian |
hu_HU.UTF-8 |
HU_HU.UTF-8 |
hu_HU.utf8 |
|
Italian |
it_IT.UTF-8 |
IT_IT.UTF-8 |
it_IT.utf8 |
|
Japanese |
ja_JP.UTF-8 |
JA_JP.UTF-8 |
ja_JP.utf8 |
|
Korean |
ko_KR.UTF-8 |
KO_KR.UTF-8 |
ko_KR.utf8 |
|
Norwegian |
no_NO.UTF-8 |
NO_NO.UTF-8 |
no_NO.utf8 |
|
Polish |
pl_PL.UTF-8 |
PL_PL.UTF-8 |
pl_PL.utf8 |
|
Portuguese |
pt_PT.UTF-8 |
PT_PT.UTF-8 |
pt_PT.utf8 |
|
Portuguese-Brazilian |
pt_BR.UTF-8 |
PT_BR.UTF-8 |
pt_BR.utf8 |
|
Romanian |
ro_RO.UTF-8 |
RO_RO.UTF-8 |
ro_RO.utf8 |
|
Russian |
ru_RU.UTF-8 |
RU_RU.UTF-8 |
ru_RU.utf8 |
|
Slovak |
sk_SK.UTF-8 |
SK_SK.UTF-8 |
sk_SK.utf8 |
|
Spanish |
es_ES.UTF-8 |
ES_ES.UTF-8 |
es_ES.utf8 |
|
Swedish |
sv_SE.UTF-8 |
SV_SE.UTF-8 |
sv_SE.utf8 |
|
Thai |
th_TH.UTF-8 |
TH_TH.UTF-8 |
th_TH.utf8 |
|
Turkish |
tr_TR.UTF-8 |
TR_TR.UTF-8 |
tr_TR.utf8 |
Oracle BI Presentation Servicesでは、エラー・メッセージの言語はNQ_SESSION.WEBLANGUAGEセッション変数に基づいて設定されます。プレゼンテーション・サービスでは、インストレーション時にこの変数のデフォルト値が指定されます。この値は、ユーザーがOracle BI EEサインイン・ページで言語を選択すると更新されます。
サード・パーティのクライアントを含むその他のクライアントでは、エラー・メッセージの言語は次の優先順位モデルにより決定されます。
エラー・メッセージの言語はWEBLANGUAGEセッション変数に基づいて設定されます。
WEBLANGUAGEセッション変数が設定されていない場合は、Oracle BI Serverへのアクセスで使用されるODBCデータ・ソース名(DSN)に指定されたエラー言語に基づいて設定されます。
ODBC DSNでのエラー・メッセージ言語の設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』を参照してください。
ODBC DSNにエラー・メッセージの言語が設定されていない場合は、ORACLE_BI_LANG環境変数で指定されている言語がエラー・メッセージに対して使用されます。
ORACLE_BI_LANGの値を変更するには、opmn.xmlでこの変数の文字コードを更新します。サポートされている言語の文字コードは、ORACLE_HOME/bifoundation/server/localeディレクトリで確認できます(たとえば、enは英語を表し、pt-BRはポルトガル語/ブラジル語を表します)。
ORACLE_BI_LANG環境変数が設定されていない場合、エラー・メッセージは英語で表示されます。
管理ツールおよびジョブ・マネージャのクライアントでは、WEBLANGUAGEセッション変数は設定されないので注意してください。したがって、これらのクライアントは、ODBC DSNエラー・メッセージ設定以降の優先順位モデルに従います。
この項では、Oracle BI Serverでの現在のロケールに関するトラブルシューティングについて説明します。
適切なロケールがインストールされていない場合、Oracle BI Serverは起動せず、NQSServer.logファイルに次のエラーが格納されます。
[47013] NLSのロケールxxxは、このオペレーティング・システムでサポートされていません。
xxxは、NQSConfig.INIファイルでSORT_ORDER_LOCALEパラメータに指定されているロケールです。このエラーを解決するには、次の操作を実行します。
UNIXの場合。表15-2に示すロケールのうち、必要な言語に対応するものをインストールします。
Windowsの場合。「地域の設定」ダイアログを使用して、対応する言語パックを追加します。
AIXプラットフォームで日本語ローカライゼーションを使用すると、Oracle BI Serverが起動しないことがあります。この問題が発生した場合は、次の手順を実行します。
AIXシステムで日本語ロケールを設定するには:
JA_JP.UTF-8ロケールがインストールされていることを確認します。インストールされていない場合はインストールします。
第3.4項「構成設定を更新するためのテキスト・エディタの使用」の説明に従い、NQSConfig.INIファイルを開いて編集します。
Generalセクションで、次のパラメータを設定します。設定では大文字と小文字が区別されるので注意してください。
LOCALE = "Japanese";
SORT_ORDER_LOCALE = "Japanese";
NQSConfig.INIファイルを保存して閉じます。
管理ツールの「文字列の外部化」ユーティリティを使用すると、プレゼンテーション・レイヤーのサブジェクト・エリア名、表名、階層名、列名およびそれらの説明をローカライズできます。これらのテキスト文字列は、ANSI、UnicodeおよびUTF-8エンコーディング・オプションを使用して外部ファイルに保存できます。
ローカライズ対象の文字列を外部化するには:
管理ツールでリポジトリを開きます。
サブジェクト・エリア、プレゼンテーション表またはプレゼンテーション列など、プレゼンテーション・レイヤーのオブジェクトを右クリックし、「表示名の外部化」→「カスタム名の生成」を選択するか、「記述子の外部化」→「カスタム説明の生成」を選択して文字列を外部化します。
これらの外部化オプションのいずれかを選択すると、選択したオブジェクトとそのすべての子オブジェクトについて、「プロパティ」ダイアログの「カスタム表示名」オプションまたは「カスタム説明」オプションが自動的に選択されます。
たとえば、サブジェクト・エリアを右クリックして外部化オプションのいずれかを選択すると、サブジェクト・エリア内のすべてのプレゼンテーション表、列、階層およびレベルに対して外部化フラグが設定されます。
「ツール」を選択し、「ユーティリティ」を選択します。
「文字列の外部化」を選択し、「実行」をクリックします。
「文字列の外部化」ダイアログの左側のペインで、サブジェクト・エリアを選択します。
サブジェクト・エリアをすべて一度に選択するか個々に選択して、各サブジェクト・エリアに個別の文字列ファイルを作成できます。
右側のペインに、翻訳済の値と元の文字列(名前および説明)が表示されます。これらは、プレゼンテーション・サービスで使用されるセッション変数の値になります。
プレゼンテーション・レイヤーで外部化フラグが設定されているオブジェクトのみ右側のペインに表示されます。
「保存」をクリックします。
「名前を付けて保存」ダイアログで、ファイル・タイプおよびエンコーディング値を選択し、「保存」をクリックします。
外部化された文字列ダイアログで、「閉じる」をクリックします。
(オプション)外部化を無効にするには、プレゼンテーション・レイヤーのオブジェクトを右クリックし、「表示名の外部化」→「外部化の無効化」を選択するか、「記述子の外部化」→「外部化の無効化」を選択します。
これらのオプションのいずれかを選択すると、選択したオブジェクトとそのすべての子オブジェクトについて、「プロパティ」ダイアログの「カスタム表示名」オプションまたは「カスタム説明」オプションが自動的に選択解除されます。
「文字列の外部化」ユーティリティを使用して文字列ファイルを作成した場合は、次の手順に従い、そのファイルを使用してメタデータ・オブジェクトの文字列を翻訳できます。
エクスポートされた文字列ファイルを使用してメタデータの文字列を翻訳するには:
文字列ファイルを開いて次の列を調べます。
1列目には、実際のリポジトリ・オブジェクトの名前が記述されています。。この名前には、オブジェクトのタイプと接頭辞が含まれます。
2列目には、各オブジェクトの名前または説明に対応するセッション変数が記述されています。。これらには、カスタム名を示すデフォルト接頭辞のCN_、またはカスタム説明を示すデフォルト接頭辞のCD_が含まれます。
ファイルの3列目に各オブジェクトの名前の翻訳を入力するよう、翻訳チームに要請します。
Languageという名前の4番目の列を追加します。この列で、deなど、名前が翻訳された言語のコードを指定します。
文字列ファイルをデータベース表にロードします。
管理ツールで、この表を物理レイヤーにインポートします。
行単位の初期化ブロックを使用して、翻訳済の文字列をロードします。初期化ブロックのターゲットが「行単位の初期化」に設定されていること、および実行優先順位が正しく設定されていることを確認します。
たとえば、次の手順を実行します。
次のようなSQL文を使用して、データベースからのデータ・ソースを含むセッション初期化ブロックを作成します。
SELECT 'VALUEOF(NQ_SESSION.WEBLANGUAGE)' FROM DUAL
設定言語の「セッション変数初期化ブロック」ダイアログで、「変数ターゲット」にLOCALEセッション変数を指定します。
これにより、ユーザーがサインインするときは常に、WEBLANGUAGEセッション変数が設定されるようになります。その後、この変数によって、LOCALE変数が初期化ブロックを使用して設定されます。
セッション変数初期化ブロックのデータソースダイアログで、次のようなデータベース固有のSQL文を使用して、一連のセッション変数を作成する別のセッション初期化ブロックを作成します。
select SESSION_VARIABLE, TRANSLATION from external where LANGUAGE = 'VALUEOF(NQ_SESSION.LOCALE)'
このブロックで作成されるすべての変数の言語は、サインイン時にユーザーが指定した言語に一致します。
セッション変数初期化ブロックの変数ターゲットダイアログで、初期化ブロックのターゲットを「行単位の初期化」に設定します。
「セッション変数初期化ブロック」ダイアログの「実行優先度」領域で、前に作成した初期化ブロックを指定して、最初に作成したブロックが最初に実行されるようにします。
変更を保存します。
|
ヒント: Oracle Application Development Frameworkデータ・ソースを使用する場合は、「文字列の外部化」ユーティリティを使用するかわりに、そのデータ・ソースからラベルおよびツールチップを伝播できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。 |
この項では、複数の言語でフィールド情報を表示できるようにOracle BI Serverを構成する方法について説明します。内容は次のとおりです。
管理ツールの使用の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
多言語データのサポートとは、データベース・スキーマのデータを複数の言語で表示する機能です。Oracle BI Serverは、翻訳の管理を簡素化し、その問合せパフォーマンスを改善することによって多言語スキーマをサポートします。多言語スキーマでは、通常、翻訳済フィールドが参照表と呼ばれる個別の表に格納されます。参照表には記述子列の翻訳が複数言語で格納され、ベース表にそのデータが元の言語で格納されます。記述子列は、キー列のテキストによる説明を提供します。記述子列とキー列の間には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つがあります。
多くの場合、ベース表ごとに個別の参照表があります。参照表には、ベース表内のレコードへの外部参照キーが含まれ、各翻訳済フィールドの値が個別の列に含まれます。参照表が完全に密である場合、特定言語用の参照表内の行数は、ベース表内の行数と等しくなります。
図15-5の例は、ベース表内の1つの行のみに一致する、参照表内の各レコードを示しています。
ベース表ごとに1つの参照表を使用するかわりに、図15-6に示すように、翻訳済フィールドごとに個別の参照表を使用する方法があります。各フィールドの翻訳済値を取得するには、参照表に対する個別の結合が必要です。実際には、これは多くの場合、複数フィールドの翻訳を含む1つの物理表になります。単一の表に複数フィールドの翻訳が含まれる場合は、参照表にフィルタを設定して、データを、ベース表内の特定の列に関連する値のみに制限する必要があります。
この項では、論理参照表および論理参照列の作成について説明します。内容は次のとおりです。
ビジネス・モデルで論理参照表オブジェクトを作成して、翻訳参照表に必要なメタデータを定義します。第15.6.5.2項「論理表の参照表としての指定」で説明しているように、参照表とは、自身を参照表として指定するプロパティを持つ論理表のことです。図15-7は、参照表の例を示しています。
参照表の各主キーをまとめて参照キーと見なし、参照が実行されます。参照は、すべての参照キー列に値が指定されている場合にのみ実行できます。たとえば、図15-7では、Product_CodeとLanguage_Keyの組合せによってこの参照表の主キーが形成されます。
参照キーは論理表キーとは異なります。参照キー列ではその順序が考慮されます。たとえば、Product_CodeとLanguage_Keyを組み合せた参照キーは、Language_KeyとProduct_Codeを組み合せた参照キーとは異なると見なされます。参照キー列の順序は管理ツールで指定できます。参照キーのすべての列は参照関数で結合する必要があります。
参照表には参照キーが1つのみ含まれます。
参照表には少なくとも1つの値列が含まれます。図15-7では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の翻訳済の値を戻します。
参照関数を含む論理列を作成するには、管理ツールで式ビルダーを使用します。論理列の値は、現在のユーザーに関連付けられている言語に基づきます。
たとえば、翻訳済の製品名を取得するには、「列ソース」タブで、導出された列式を使用して新しい論理列を作成します。
INDEXCOL( VALUEOF(NQ_SESSION."LAN_INT"), "Translated Lookup Tables"."Product". "ProductName", LOOKUP( DENSE "Translated Lookup Tables"."Product Translations". "ProductName", "Translated Lookup Tables"."Product"."ProductID", VALUEOF(NQ_SESSION."WEBLANGUAGE")))
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関数の結果である導出論理列を、1次論理レベル・キーの一部として使用することはできません。集計が行われた後にLOOKUP操作が適用されるため、この制限が存在します。ただし、レベル・キー列によって集計の計算粒度が定義されるため、レベル・キー列は集計を行う前に使用可能にしておく必要があります。
|
非ISOタイプの言語コードの処理
表内のデータに非ISOタイプの言語コードが含まれる場合は、ISO言語コードを非ISO言語コードにマップする表が必要になります。ユーザーのログイン時にISO言語コードを設定する既存のWEBLANGUAGE変数を使用できます。個別のLANGUAGE変数を定義し、その初期化ブロックでマッピング表に対して問合せを実行して、WEBLANGUAGE変数の値でフィルタされた非ISO言語コードをフェッチします。表15-3に、非ISO言語コードのマッピング表を示します。LANGUAGEが非ISO言語コードです。
ビジネス・モデルで物理参照表オブジェクトを作成して、翻訳参照表に必要なメタデータを定義できます。物理参照表は、その意味と使用方法の両方において論理参照表に類似しています。物理参照表は、論理参照表で処理できない次のシナリオに対処します。
参照表ソースが断片化されている。この場合、複数の物理参照表を使用して値を保持します。たとえば、断片化されている製品名データの翻訳値を、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)を右クリックし、「新規オブジェクト」、「論理列」の順に選択して新しい論理列を作成します。
論理列の名前(たとえば、categoryname_p)を指定します。
「列ソース」タブを選択します。
「物理マッピングから派生」の下の「論理表ソース」ボックスで、ベース表列を含む論理表ソース・オブジェクトをダブルクリックします。「論理表ソース」ダイアログの「列マッピング」タブが表示されます。
「マップされていない列の表示」が選択されていることを確認します。
新しい論理列(たとえば、categoryname_p)の「式」列に、次のような式を入力します。
INDEXCOL(VALUEOF(NQ_SESSION."LAN_INT"), "DB_Name"."My_Category"."My_Schema"."Categories"."CategoryName", LOOKUP(SPARSE "DB_Name"."My_Category"."My_Schema"."CATEGORIES_TRANS"."CATEGORYNAME", "DB_Name"."My_Category"."My_Schema"."Categories"."CategoryName", "DB_Name"."My_Category"."My_Schema"."Categories"."CategoryID", VALUEOF(NQ_SESSION."LANGUAGE")))
式ビルダーを使用して作成することもできます。
「論理表ソース」ダイアログで「OK」をクリックします。
「論理列」ダイアログで「OK」をクリックします。
変更を保存します。
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関数の完全な構文の情報は、第15.6.5項「論理参照表および論理参照列の作成」を参照してください。
多くの場合、Essbaseキューブのメンバーは、ユーザー言語ごとに個別の別名を用意して、ユーザーが自分の言語でメンバー名を表示できるようにします。通常、セッション変数を定義して、ユーザーのログイン時に適切な別名を動的に選択します。Essbase別名表、およびセッション変数でのそれらの使用方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
辞書編集上の差異によるソートは、データをアルファベット順にソートする機能です。ほとんどのデータ・ソースは辞書編集上の差異によるソートをサポートしています。ただし、辞書編集上の差異によるソートが特定のデータ・ソースに対して適切に動作しない場合、Oracle BI Serverを構成して、バックエンド・データ・ソース以外でソートを実行できます。この構成を実行するには、管理ツールの「データベース」ダイアログの「機能」タブで、ORDERBY_SUPPORTEDが選択解除されていることを確認します。データベース機能の指定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。
データ・ソースでORDERBY_SUPPORTEDを無効にすると、パフォーマンスに非常に大きな影響を与える場合があるので注意してください。これは、無効にした結果、多数の結合がデータ・ソースにプッシュダウンされないためです。多くの場合、パフォーマンスへの影響は非常に大きいため、辞書編集上の差異によるソート機能への影響に関係なく、ORDERBY_SUPPORTEDはデータ・ソースで有効にしておく必要があります。
