Oracle® Business Intelligence Applications

管理者ガイド

11gリリース1 (11.1.1.8.1)

E56354-01(原本部品番号:E51483-01)

2014年3月

カスタマイズ、複数言語のサポート、デプロイメントのローカライズ、高可用性、Endeca DiscoveryオプションおよびOracle GoldenGateの使用方法など、システム管理者が関心を持つトピックを提供します。

Oracle Business Intelligence Applications管理者ガイド, 11gリリース1 (11.1.1.8.1)

E56354-01

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.

原本主著者:  Dan Hilldale

原本協力著者: Oracle Business Intelligence開発チーム、製品管理チームおよび品質保証チーム

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle Business Intelligence Applications Administrationの新機能

- Oracle BI Applicationsシステム管理者向けの新機能

1 Oracle Business Analytics Warehouseのカスタマイズ

- 1.1 Oracle Business Intelligence Applicationsのカスタマイズの概要

- 1.1.1 Oracle Business Intelligence Applicationsのカスタマイズとは

- 1.1.2 カスタマイズ・プロセスについて

- 1.1.3 カスタマイズに対するパッチ・インストールの影響について

- 1.2 カテゴリ1のカスタマイズ: 既存のファクト表またはディメンション表への列の追加

- 1.2.1 マッピングの拡張について

- 1.2.2 Oracle Business Analytics Warehouseでのマッピング拡張の標準的な手順

- 1.2.3 特別な処理が必要なその他のタイプのカスタマイズ

- 1.2.3.1 カテゴリ2のSCDの動作を変更する方法

- 1.2.3.2 既存のファクトにディメンションを追加する方法

- 1.2.3.3 ファクトにDATE_WID列を追加する方法

- 1.3 カテゴリ2のカスタマイズ: 表の追加

- 1.3.1 表の新規作成について

- 1.3.1.1 主要な必須列について

- 1.3.2 DATASOURCE_NUM_ID列について

- 1.3.3 カスタマイズに関する追加情報

- 1.3.3.1 更新戦略について

- 1.3.3.2 索引と命名規則について

- 1.3.5 Oracle Business Analytics Warehouseへの新しいファクト表の追加

- 1.4 カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加

- 1.4.1 標準的なディメンション表に新しいデータを行全体として追加する方法

- 1.4.2 抽出の構成

- 1.4.2.1 追加データの抽出

- 1.4.2.2 ソース・ファイルのデリミタの設定

- 1.4.3 ロードの構成

- 1.4.3.1 プライマリ抽出マッピングおよび削除マッピングのプロセスについて

- 1.4.3.2 プライマリ抽出マッピングおよび削除マッピングを使用した作業について

- 1.5 ストアド・ルックアップのカスタマイズおよび索引の追加

- 1.5.1 ストアド・ルックアップについて

- 1.5.1.1 ディメンション・キーの解決について

- 1.5.2 既存のファクト表またはディメンション表に索引を追加する方法

- 1.6 RPDのトリミング

- 1.6.1 完全なRPDからのプロジェクトの抽出

- 1.6.1.1 ディメンション・キーの解決について

2 複数言語のサポートについて

- 2.1 複数言語サポートの概要

- 2.2 擬似翻訳について

- 2.3 Oracle BI Applicationsのドメインについて

- 2.4 ディメンション翻訳表について

3 Oracle Business Intelligenceのデプロイメントのローカライズ

- 3.1 Oracle BI EE用翻訳表のメンテナンスのプロセス

- 3.1.1 英語以外のロケールに対するOracle Business Intelligenceシード・データのアップグレード

- 3.1.1.1 翻訳表(W_LOCALIZED_STRING_G)および対応する索引の確認

- 3.1.1.2 翻訳表(W_LOCALIZED_STRING_G)へのロケール・シード・データのインポート

- 3.1.2 顧客のメタデータ文字列の外部化

- 3.1.3 W_LOCALIZED_STRING_G表へのカスタム翻訳の追加

- 3.1.3.1 Analyticsメタデータに対する文字列翻訳の追加

- 3.2 Presentation Services文字列の翻訳について

- 3.3 Analyticsアプリケーションのデフォルト通貨の変更

4 Oracle Business Analytics Warehouseの命名規則

- 4.1 Oracle Business Analytics Warehouseの表の命名規則

- 4.2 Oracle Business Analytics Warehouseの表のタイプ

- 4.2.1 Oracle Business Analytics Warehouseの集計表

- 4.2.2 Oracle Business Analytics Warehouseのディメンション・クラス表

- 4.2.3 Oracle Business Analytics Warehouseのディメンション表

- 4.2.4 ビジネス・ロール・ベースのフラグを持つディメンション表

- 4.2.5 Oracle Business Analytics Warehouseのファクト表

- 4.2.6 Oracle Business Analytics Warehouseのヘルパー表

- 4.2.7 Oracle Business Analytics Warehouseの階層表

- 4.2.8 Oracle Business Analytics Warehouseのミニ・ディメンション表

- 4.2.9 Oracle Business Analytics Warehouseのステージング表

- 4.2.10 Oracle Business Analytics Warehouseの翻訳表

- 4.3 Oracle Business Analytics Warehouseの内部表

- 4.4 Oracle Business Analytics Warehouseの列の標準接頭辞

- 4.5 Oracle Business Analytics Warehouseの列の標準接尾辞

- 4.6 Oracle Business Analytics Warehouseの表のシステム列

- 4.7 システム列での複数通貨のサポート

- 4.8 Oracle Business Analytics Warehouseのプライマリ・データ値

- 4.9 Oracle Business Analytics Warehouseでの複数言語のサポートについて

- 4.10 Oracle Business Analytics Warehouseでの通貨のプリファレンス

5 Oracle Business IntelligenceのEndeca Discoveryオプション

- 5.1 はじめに

- 5.2 EndecaとOracle BI Applicationsの統合の設定

- 5.3 Oracle EndecaとOracle BI Applicationsを組み合せて設定する際のタスク

- 5.3.1 設定手順: Oracle Endeca Serverのインストール

- 5.3.2 設定手順: Endeca 3.1 Studioのインストール

- 5.3.3 設定手順: Oracle BIおよびEndecaのためのODI接続の設定

- 5.3.4 設定手順: データのロード

- 5.3.5 設定手順: Endecaアプリケーションの新規作成

- 5.4 ODIパッケージ、インタフェースおよびプロシージャの設計の概要

- 5.5 サンプル・アプリケーションのデプロイ

- 5.6 カスタムBIアプリケーションのセキュリティ・マネージャの適用

- 5.7 トラブルシューティング

6 データ系統の調査

- 6.1 はじめに

- 6.2 データ系統の設定

- 6.3 データ系統ダッシュボードを設定するためのタスク

- 6.3.1 設定手順: ODIトポロジおよびロード計画の構成

- 6.3.2 設定手順: RPDおよびプレゼンテーション・カタログの抽出スクリプトの構成

- 6.3.3 設定手順: データ系統ウェアハウスの表の作成

- 6.4 データ系統ダッシュボードをロードおよびリフレッシュするためのタスク

- 6.4.1 スクリプトを使用したOracle Business Intelligenceのメタデータの抽出

- 6.4.2 データ系統ロード計画の実行および監視

- 6.5 データ系統ダッシュボードを使用した分析の実行

- 6.5.1 Oracle BI Applicationsデータ系統ダッシュボードの概要

- 6.5.2 Oracle Business Intelligence Applicationsのためのデータ系統の分析

索引

はじめに

Oracle Business Intelligence Applicationsは、包括的なビルトイン・ソリューションであり、組織全体に幅広くインテリジェンスをもたらします。業務効率の最大化に必要となる重要な情報を、現場の従業員から経営陣まで、あらゆるレベルのユーザーに提供します。直感的に操作可能な役割ベースの本ソリューション群により、様々なエンタープライズ・ソースおよび企業のデータ・ウェアハウスのデータを実用的な洞察へと変換・統合し、より効果的なアクション、決定、プロセスを実現します。

Oracle BI Applicationsは、Oracle Business Intelligence Suite Enterprise Edition (Oracle BI EE)上に構築されています。Oracle BI EEは、エンタープライズ・ビジネス・インテリジェンス・ツールおよびインフラストラクチャの包括的なセットであり、これには、スケーラブルで効率的な問合せおよび分析サーバー、非定型の問合せおよび分析ツール、インタラクティブ・ダッシュボード、プロアクティブ・インテリジェンスおよびアラート、エンタープライズ・レポート・エンジンなどが含まれます。

対象読者

このドキュメントは、Oracle BI Applicationsの管理を担当するシステム管理者およびETLチーム・メンバーを対象としています。ETLのカスタマイズ、ドメインおよびローカライゼーション、Oracle Business Analytics Warehouseの命名規則、およびシステム管理タスク(ETLのパフォーマンスをサポートするOracle GoldenGateおよびソース依存スキーマの設定と使用方法を含む)について説明します。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs(聴覚障害者向け)を参照してください。

関連ドキュメント

関連するOracle Business Intelligence Applicationsドキュメントのリストについては、Oracle Business Intelligence Applicationsドキュメント・ライブラリhttp://docs.oracle.com/cd/E51479_01/index.htmを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調、またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle Business Intelligence Applications Administrationの新機能

ここでは、管理に関連するOracle Business Intelligence Applicationsの機能について説明します。

Oracle BI Applicationsシステム管理者向けの新機能

Endecaの統合

Oracle BI Applicationsは、オプションでOracle Endeca Information Discoveryを利用できます。Oracle Endeca Information Discoveryは、構造化されたソース、非構造化ソースの両方の情報を分析するための エンタープライズ・ディスカバリ・プラットフォームです。タグ・クラウドなど、様々な多くの方法でデータを視覚化する機能を備えています。

Oracle BI ApplicationsとOracle Endeca Information Discoveryを統合することにより、非構造化データを分析できるようになります。Oracle Endeca Information Discoveryは、Endecaアプリケーションをロードするために実行できるODIマップを備え、100を超えるOracle BI Applicationサブジェクト領域を対象としており、一部のOracle BI Applicationsに対してソース・システムから非構造化テキスト・フィールドへのアクセス権を付与します。これにより、ユーザーは構造化されたBIデータを新しい方法で調査できます。

1 Oracle Business Analytics Warehouseのカスタマイズ

この章では、Oracle Business Intelligence ApplicationsにおけるETL機能のカスタマイズの概念と手法について説明します。また、Oracle BI Applicationsメタデータ・リポジトリをトリミングするために使用されるプロセスについても説明します。

この章の内容は次のとおりです。

- 第1.1項「Oracle Business Intelligence Applicationsのカスタマイズの概要」

- 第1.2項「カテゴリ1のカスタマイズ: 既存のファクト表またはディメンション表への列の追加」

- 第1.3項「カテゴリ2のカスタマイズ: 表の追加」

- 第1.4項「カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加」

- 第1.5項「ストアド・ルックアップのカスタマイズおよび索引の追加」

- 第1.6項「RPDのトリミング」

1.1 Oracle Business Intelligence Applicationsのカスタマイズの概要

この項では、Oracle Business Intelligence Applicationsのカスタマイズの概要について説明します。この項の内容は次のとおりです。

- 第1.1.1項「Oracle Business Intelligence Applicationsのカスタマイズとは」

- 第1.1.3項「カスタマイズに対するパッチ・インストールの影響について」

1.1.1 Oracle Business Intelligence Applicationsのカスタマイズとは

Oracle Business Intelligence Applicationsでは、カスタマイズは、新しい情報をビジネス・インテリジェンス・ダッシュボードで分析できるようにするための事前構成された動作の変更として定義されます。たとえば、データをフィールドHZ_CUST_ACCOUNTS.ATTRIBUTE1から抽出し、Oracle Business Analytics WarehouseのX_ACCOUNT_LOGフィールドに格納することによって、列をダッシュボードに追加する必要がある場合があります。

使用しているデータ・ソースのタイプによって、実行できるカスタマイズのタイプが決まります。データ・ソースは、次のいずれかのタイプになります。

- パッケージされたアプリケーション(たとえば、Oracle FusionまたはEBS)。事前パッケージ済アダプタを使用します。

- パッケージされていないデータ・ソース。汎用アダプタを使用します。

カスタマイズは、次のカテゴリに分類されます。

- カテゴリ1。カテゴリ1のカスタマイズでは、事前にパッケージされているアダプタを持つソース・システムから列を追加し、データを既存のOracle Business Analytics Warehouse表にロードします。カテゴリ1のカスタマイズの実行の詳細は、第1.2項「カテゴリ1のカスタマイズ: 既存のファクト表またはディメンション表への列の追加」を参照してください。

- カテゴリ2。カテゴリ2のカスタマイズでは、事前にパッケージされているアダプタを使用して、新しいファクト表またはディメンション表をOracle Business Analytics Warehouseに追加します。カテゴリ2のカスタマイズでは、通常、新しいSDEマッピングおよびSILマッピングを構築する必要があります。カテゴリ2のカスタマイズの実行の詳細は、第1.3項「カテゴリ2のカスタマイズ: 表の追加」を参照してください。

- カテゴリ3。カテゴリ3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされているアダプタがないソースからデータをロードします。カテゴリ3のカスタマイズの実行の詳細は、第1.4項「カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加」を参照してください。

次の図に、データ・ソースのタイプおよび変更のタイプごとに実行できるカスタマイズのカテゴリがまとめられています。

図1-1 データソースに基づいてサポートされているカスタマイズ

表および命名規則の詳細は、『Oracle Business Analytics Warehouseデータ・モデル・リファレンス』を参照してください。

ETLのパッケージおよびインタフェースをカスタマイズするときは、通常、ODI Studioのデザイナ・ナビゲータの「プロジェクト」ビューにある\Oracle BI Applications\Mappingsフォルダで作業します。

注意: このカスタマイズ方法では、ETLタスクをコピーして、オリジナルとコピーの両バージョンを作成します。このとき、データストアはバージョニングのみが行われます。これらのバージョンを使用することで、必要に応じて機能を元に戻したり、カスタマイズ、パッチまたはアップグレードを通して取り込まれた変更内容を特定できます。

1.1.2 カスタマイズ・プロセスについて

この章では、ビジネス分析とテクニカル分析を実行した後に、ETL機能をカスタマイズする方法について説明します。この章では、次に示す実行する必要があるタスク以外の通常のタスクについては説明しません。

- ビジネス分析: カスタマイズを開始する前に、通常、現在のBIダッシュボードを分析し、ビジネスまたは組織をサポートするために必要な変更を判別します。

- テクニカル分析: ビジネス要件を特定したら、変更する必要があるソース表、ステージング表、ターゲット表およびODIのパッケージとインタフェースを特定して、実行する必要があるテクニカル変更を判別する必要があります。

- RPD変更: ETL機能のカスタマイズを実行したら、RPDを変更して、新しいデータをダッシュボードに公開する必要があります。RPDの変更の詳細は、Oracle Business Intelligence Enterprise Editionのドキュメント・ライブラリを参照してください。

1.1.3 カスタマイズに対するパッチ・インストールの影響について

この項では、パッチが適用済のオブジェクトにカスタマイズ内容を再適用する際に実行する必要がある作業について説明します。たとえば、Supply Chain and Order Managementアプリケーションを変更するOracle Business Intelligence Applicationsのパッチをインストールする場合、Supply Chain and Order Managementアプリケーションに対して行ったカスタマイズ内容を手動で再適用することが必要になる場合があります。

ETLタスクのカスタマイズの一環として(特定のタスク・フォルダの下にあるインタフェースとパッケージを含む)、カスタマイズ対象のタスク・フォルダをコピーして、オリジナル・バージョンとコピー・バージョンを作成します。オリジナル・タスクの現行バージョンにすべてのパッチが適用されます。ODIのバージョン比較ユーティリティを利用して、パッチによって取り込まれた変更を特定します。取り込まれた変更を分離できるようにするために、コピー・バージョンも作成されます。すべての変更内容をパッチで取り込まれた変更内容と比較し、競合がないことを確認してから、そのパッチで取り込まれた変更内容をカスタマイズ済のETLタスクに手動で適用します。ETLのカスタマイズ内容の変更とバージョニングの詳細は、第1.2.2項「Oracle Business Analytics Warehouseでのマッピング拡張の標準的な手順」を参照してください。

パッチによってインストールされるのは、作業リポジトリ全体ではなく、変更されたリポジトリ・オブジェクトのみです。したがって、パッチによって変更されたマッピングに対してのみカスタマイズ内容を再適用する必要があります。たとえば、パッチによってSupply Chain and Order Managementアプリケーションのみが変更される場合、Supply Chain and Order Managementアプリケーションに対して行ったカスタマイズ内容のみを手動で再適用する必要があります。他のアプリケーションのカスタマイズ内容は、パッチの影響を受けません。

注意

すべてのカスタマイズ手順で、カスタマイズ済のETLタスクを格納する「カスタム」アダプタ・フォルダを作成します。これは必須ではありませんが、カスタマイズされた内容を簡単に特定するためのベスト・プラクティスと考えられます。

1.2 カテゴリ1のカスタマイズ: 既存のファクト表またはディメンション表への列の追加

カテゴリ1のカスタマイズでは、事前にパッケージされているアダプタを持つソース・システムから列を追加し、データを既存のOracle Business Analytics Warehouse表にロードします。

この項の内容は次のとおりです。

- 第1.2.1項「マッピングの拡張について」

- 第1.2.2項「Oracle Business Analytics Warehouseでのマッピング拡張の標準的な手順」

- 第1.2.3項「特別な処理が必要なその他のタイプのカスタマイズ」

1.2.1 マッピングの拡張について

カテゴリ1のカスタマイズでは、事前にパッケージされたアダプタが含まれているソース・システム(Oracle eBusiness Suiteなど)から追加のカラムを抽出し、既存のOracle Business Analytics Warehouse表にデータをロードします。カテゴリ1のカスタマイズの場合、データはパッケージされていないソースからも入力されますが、この項では、このソースはすでに汎用アダプタでマッピングされ、追加の列を取り込むための拡張のみが必要であると想定しています。(汎用アダプタの初期マッピングは、カテゴリ3のカスタマイズで検討します。詳細は、第1.4項「カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加」を参照。)

Oracle Business Analytics Warehouseで追加の列を参照するには、まずその列がETLプロセスで渡されている必要があります。既存のマッピングと表は拡張可能です。Oracle Business Intelligence Applicationsでは、事前に構成済のマッピングを拡張し、これらの列を追加して、既存の表にデータをロードする方法論が提供されています。

Oracle Business Intelligence Applicationsには、拡張と変更という2種類のカスタマイズがあります。サポートされている拡張ロジックにより、既存オブジェクトに追加できます。たとえば、ソースから追加の列を抽出し、既存のマッピングを使用して追加の列を渡し、既存の表に新しい列を追加移入できます。一般的に、Oracle Business Intelligence Applicationsでは、既存のロジックまたは列を変更することはできません。別の列を使用するために既存の計算を変更することはできません。また、既存の列を別のソースからロードするように再マッピングすることもできません。

たとえば、既存のロジックと異なる方法で売上を計算する場合は、新しい列(X_REVENUEなど)を作成して、その列にカスタム・マッピング式を移入する必要があります。その後、Oracle Business Intelligenceリポジトリを再マッピングして、新しいX_REVENUE列を指すようにできます。

ほとんどのデータストアには、X_CUSTOMという名前のプレースホルダ列が1つあります。各ETLタスクには、この列にデータを移入するためのマッピング式があります。これらの式は、ODIのデータストアとインタフェースをカスタマイズする際のテンプレートとして機能します。新しいカスタム列の作成時には、カスタム列を識別できるようにX_接頭辞を含める命名規則に従います。

次の図では、事前に構成済のロジックがグレーで表示されています。これらのオブジェクトの内容には、どのような変更もできません。パッケージとインタフェースを新たに作成するのではなく、既存のオブジェクトにカスタマイズ部分を追加する必要があり、これにより既存のロジックとパラレルで追加部分を実行できます。

図1-2 事前に構成済のロジックとカスタマイズ部分

1.2.2 Oracle Business Analytics Warehouseでのマッピング拡張の標準的な手順

Oracle Business Analytics Warehouseを拡張する最も一般的な理由は、ソース・システムから既存の列を抽出して、Oracle Business Analytics Warehouseの既存の表(ファクトまたはディメンション)にマッピングするためです。このタイプの変更では通常、SILパッケージ内でのインタフェースの拡張が必要になります。パッケージ化されたソースからデータが取得される場合は、該当するSDEアダプタ・パッケージ内のインタフェースも拡張する必要があります。パッケージ化されていないソースからデータが取得される場合は、汎用アダプタ・パッケージを使用する必要があります。該当するパッケージが存在しない場合には、インタフェースとともに汎用アダプタ・パッケージを作成する必要があります。

Oracle Business Analytics WarehouseでODIパッケージを拡張するには:

1. SDEおよびSILアダプタの新しいフォルダを作成します(既存の「アダプタ」フォルダをコピーしないでください。サブフォルダがすべてコピーされてしまうからです)。フォルダの名前には、「Custom」または他のわかりやすい識別子を含めるようにし、また、既存の「アダプタ」フォルダのリリース・タグと一致するようにリリース・タグを設定します。SDEとSILの両方のフォルダに対してこれを実行します。

1. 「マッピング」フォルダを右クリックして、「新規サブフォルダ」を選択します。

2. 名前を「CUSTOM _<元のフォルダ名>」に設定します。たとえば、「CUSTOM_SDE_ORA11510_Adaptor」に設定します。CUSTOM_SILOSは、カスタムのSDEおよびSILフォルダを表します。

3. 「デザイナ」タブで、「ナビゲータの接続」ボタンをクリックします。

4. 「リリース・タグの編集」を選択します。

5. お使いのソースに対応するリリース・タグを選択します。たとえば、EBS_11_5_10を選択します。

6. 作成したカスタムSDEフォルダを選択して、リリース・タグに追加します。

7. 「次へ」をクリックします。

8. 「終了」をクリックします。

9. CUSTOM_SILOSフォルダに対して前述の手順を繰り返し、BIA_11リリース・タグに関連付けます。

2. カスタマイズ対象となる事前構成済の「タスク」フォルダに対してバージョニングを有効にします。これがタスクのベース・バージョンであることをバージョン・コメントで示す必要があります。今後、このタスクに適用されるパッチでは、元のタスクと比較して変更内容を特定できるように、コメント内のバージョンを増やすことが必要になります。

1. 「タスク」フォルダを右クリックして、「バージョン」→「バージョンの作成」を選択します。

2. デフォルトのバージョン番号である1.0.0.0を受け入れます。

3. これがこのタスクのオリジナル・バージョンであることを示す説明を追加します。

3. カスタマイズ対象となる「タスク」フォルダをコピーして複製します。コピーされた「タスク」フォルダを切り取って「カスタム」アダプタに貼り付け、名前を変更して、「…のコピー」という接頭辞を削除します。

4. 手順2と同じ方法を使用して、コピーされた「タスク」フォルダのバージョニングを有効にします。これがオリジナル・バージョンであることをバージョン・コメントで示す必要があります。このバージョニングにより、カスタマイズされたタスクとオリジナル・バージョンのコピーの比較が可能になり、取り込まれたすべての変更を判別できます。

5. コピーされたタスクの別のバージョンを作成します。これがカスタマイズされたバージョンであることをバージョン・コメントで示す必要があります。前述の手順と同じ手順を使用します。

6. カスタマイズ対象のデータストアがたとえばOracle BI Applicationsに存在するように、モデルをバージョニングします。サブモデルとデータストアをバージョニングすることはできません。これがベース・バージョンまたはオリジナル・バージョンであることをバージョン・コメントで示す必要があります。

7. 新しいバージョンのモデルを作成し、ここにカスタマイズ内容が取り込まれていることをバージョン・コメントで示します。これで、複数のモデルを比較して差異を示すことができます。モデルにパッチを適用する必要がある場合は、パッチ適用済のバージョンをカスタム・バージョンおよびオリジナル・バージョンと比較できるように、再度モデルをバージョニングする必要があります。

8. カスタマイズ内容をデータストアとタスクに適用します。カスタマイズ内容は、既存の内容を上書きするのではなく、できるかぎり追加するようにしてください。たとえば、特定の列を計算する方法が気に入らない場合、新しいカスタム列を追加して、好みの方法でマッピングします。RPDでは、論理列が、元の列ではなくこの新しいカスタム列を指すようにします。

9. シナリオを生成する前に、「シナリオ命名規則」ユーザー・パラメータが%FOLDER_NAME(2)%_%OBJECT_NAME%という値を持つようにします。

10. オリジナル・タスクに関連付けられたシナリオを削除し、オリジナルと同じシナリオ名を使用してカスタム・タスクの新しいシナリオを生成します。ODIでは一意のシナリオ名を強制しているので、カスタム・タスクに同じシナリオ名を使用する必要があります。これにより、ロード計画でオリジナルのETLタスクではなくこのETLタスクが実行されるようになります。

1. 初期状態のシナリオを削除します。オリジナルの「タスク」フォルダ→「パッケージ」→<パッケージ名>→「シナリオ」→<シナリオ名>に移動します。シナリオ名をメモに取り、シナリオを右クリックして、「削除」を選択します。

2. カスタム・タスクのシナリオを生成します。カスタムの「タスク」フォルダ→「パッケージ」→<パッケージ名>に移動して、パッケージを右クリックし、「シナリオの生成」を選択します。メモを取ったオリジナルのシナリオ名を使用します。

3. 「すべての下層オブジェクトがマテリアライズされるものとしてシナリオを生成」チェック・ボックスを選択します。

4. 「OK」をクリックします。

5. 「起動パラメータ」ドロップダウンから「すべてを使用」を選択します。

6. 「OK」をクリックします。

これで、ロード計画を実行すると、オリジナル・タスクではなくカスタム・タスクが実行されるようになります。今後、インタフェースまたはパッケージのいずれかに変更を加えた場合、既存のシナリオを再生成するか、または新しいシナリオを生成できます。別のシナリオを必要とする場合を除き、既存のシナリオを再生成することをお薦めします。これを実行するには、シナリオを右クリックして、「再生成」を選択します。

11. ロード計画を再生成します。

12. ロード計画を実行します。

1.2.3 特別な処理が必要なその他のタイプのカスタマイズ

この項の内容は次のとおりです。

- 第1.2.3.1項「カテゴリ2のSCDの動作を変更する方法」

- 第1.2.3.2項「既存のファクトにディメンションを追加する方法」

- 第1.2.3.3項「ファクトにDATE_WID列を追加する方法」

1.2.3.1 カテゴリ2のSCDの動作を変更する方法

BI Applications ETLプロセスは、タイプIおよびタイプIIの緩やかに変化するディメンションの動作をサポートします。ディメンションには、タイプ1の動作についてのみ有効なものと、タイプIIの動作のサポートも有効なものがあります。タイプIIの動作をサポートするディメンションについては、様々なディメンション属性が、様々な緩やかに変化する動作を持っています(タイプIとして扱われるいくつかの属性を含む)。ディメンションに関連付けられたタイプIIの動作を有効または無効にするには:

注意: タイプIIのトラッキング・ロジックの変更が、出荷ロジックに加える必要がある唯一の変更です。

カテゴリ2のSCDトリガーを変更するには:

1. ODIデザイナで、ディメンション・データストアを変更します。

1. 「モデル」ビューで、「Oracle BI Applications」フォルダ、「Oracle BI Applications (モデル)」および「ディメンション (サブモデル)」を展開します。

2. ディメンション表をダブルクリックします。

3. 「定義」タブで、「OLAPタイプ」の値を「ディメンション」(タイプIの変更のみをサポート)または「緩やかに変化するディメンション」(タイプIIの変更をサポート)に変更します。

2. SILディメンション・タスクを変更します。

1. このディメンションにデータを移入するSILタスクに移動します。

2. 「メイン」インタフェースをダブルクリックします。

3. 「フロー」サブタブで、「ターゲット」(ORACLE_BI_APPLICATIONS)ウィンドウを選択します。

4. 「プロパティ」ウィンドウが表示されない場合、メニュー・オプション・ビュー→「プロパティ・インスペクタ」をクリックして開きます。

5. 「IKMセレクタ」の値を、「IKM BIAPPS Oracle緩やかに変化するディメンション」(タイプIIの動作を有効にする場合)または「IKM BIAPPS Oracle増分更新」(タイプIIの動作を削除する場合)に変更します。

6. シナリオを再生成します。

タイプIIの動作をサポートするように構成されているディメンションでタイプIまたはタイプIIとして扱われる列を変更する方法について次に説明します。タイプIの動作のみをサポートするようにディメンションが構成されている場合、すべての列がタイプIとして扱われるため、次の変更を行っても効果はありません。

ディメンションに関連付けられたタイプIIの動作を有効または無効にするには:

1. ODIデザイナで、ディメンション・データストアを変更します。「モデル」ビューで、「Oracle BI Applications」フォルダ、「Oracle BI Applications (モデル)」、「ディメンション (サブモデル)」および「列」を展開します。

2. SCD動作を変更する列をダブルクリックします。

3. 「説明」サブタブの「緩やかに変化するディメンションの動作」ドロップダウン・リストで、列の動作を選択します。タイプIの動作を実装するには、「変更時に上書き」を選択します。タイプIIの動作を実装するには、「変更時の行の追加」を選択します。

カスタム・ディメンションに対してタイプIIの動作を有効にする場合は、次に示すように列を設定してください。

- ROW_WID - サロゲート・キー

- INTEGRATION_ID, DATASOURCE_NUM_ID - 自然キー

- CURRENT_FLG - 現在のレコード・フラグ

- EFFECTIVE_FROM_DT - 開始タイムスタンプ

- EFFECTIVE_TO_DT - 終了タイムスタンプ

1.2.3.2 既存のファクトにディメンションを追加する方法

この項では、既存のファクトにディメンションを追加して、ディメンション・データストアとディメンション・ステージング・データストアおよび関連付けられたSDEプロセスとSILプロセスを追加する方法について説明します。この場合、新しいディメンションとの関連付けを反映するようにファクト表とファクト・ステージング表を拡張することも必要になります。この項の内容は次のとおりです。

- 第1.2.3.2.1項「カスタム・ディメンション・データストアとタスクの作成」

- 第1.2.3.2.2項「ファクトのデータストアとタスクのカスタマイズ」

1.2.3.2.1 カスタム・ディメンション・データストアとタスクの作成

カスタム・ディメンション・データストアとタスクを作成します。「Oracle BI Applications – ディメンション」モデルの下にWC_<ディメンション名>_Dデータストアを作成します。「Oracle BI Applications – ディメンション・ステージ」モデルの下にWC_<ディメンション名>_DSデータストアを作成します。WC_SAMPLE_DSおよびWC_SAMPLE_Dデータストアをテンプレートとして使用します。これらのデータストアには、必須のすべてのシステム列が含まれます。カスタム表は、出荷表と区別できるように、WC_命名規則に従う必要があります。

注意:

表が属する特定のサブモデルによって、表のメンテナンス動作が駆動されます。たとえば、ディメンション・ステージ・サブモデルの表は各ETLの実行時に常に切り捨てられますが、「ディメンション」サブモデルの表は完全なETLの実行時にのみ切り捨てられます。データストアを配置するための「カスタム」サブモデルを作成しないでください。これは、このようなサブモデルの表では、表のメンテナンスが適切に実装されないためです。

次に説明するように、ODIでディメンションを定義するには、データベースの表を作成するDDLを生成するか、またはデータベースの表を定義してBI Applications RKMによってその定義をODIにインポートします。RKMを使用する場合、インポートされた表は自動的に「その他」サブモデルに配置されるので、必要に応じてディメンション・ステージング・サブモデルおよび「ディメンション」サブモデルに移動する必要があります。また、ディメンションに対するOLAPタイプを必要に応じて、「ディメンション」または「緩やかに変化するディメンション」に設定することも必要になります。

ODIでのディメンション表の手動による作成

ODIでディメンションとタスクを手動で作成するには:

1. デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ディメンション・ステージ (サブモデル)」に移動します。

2. WC_SAMPLE_DSデータストアを右クリックして、「選択の複製」を選択します。

3. 新しいデータストアをダブルクリックして、その名前を変更します。「名前」と「リソース名」は、実際の表名に一致する必要があります。「別名」は、同じ値またはよりユーザー・フレンドリな値にすることができます。

4. 「列」サブタブで、すべての列を追加します。

5. 同じ手順を繰り返して、「ディメンション」サブモデルの下にWC_SAMPLE_Dデータストアをコピーすることによって、ディメンション表を作成します。

6. ディメンション表で、「OLAPタイプ」を「ディメンション」(タイプIのディメンションの場合)または「緩やかに変化するディメンション」(タイプIIのディメンションの場合)に設定します。

ODIへのカスタム・ディメンション表のインポート

ODIにカスタム・ディメンション表をインポートするには:

1. デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」に移動して、「Oracle BI Applicationsモデル」をダブルクリックします。

2. 「リバース・エンジニアリング」サブタブで、LIST_OF_TABLEオプションの下にインポート対象となる表を示します。複数の表をインポートする場合は、カンマ区切りリストで指定します。

3. 「リバース・エンジニアリング」ボタンをクリックして、ODIに表をインポートするセッションを開始します。

4. 「リバース・エンジニアリング」プロセスによって、「その他」サブモデルにすべての表が配置されます。W_%_DS表をディメンション・ステージ・サブモデルにドラッグ・アンド・ドロップし、W_%_D表を「ディメンション」サブモデルにドラッグ・アンド・ドロップします。

5. 新しいディメンション・データストアをダブルクリックして、「OLAPタイプ」を「ディメンション」(タイプIのディメンションの場合)または「緩やかに変化するディメンション」(タイプIIのディメンションの場合)に設定します。

カスタム・ディメンションに対するODI順序の作成

カスタム・ディメンションのODI順序を作成します。ディメンションのROW_WID列にデータを移入するために、データベース順序が使用されます。データベースのデータベース・トリガーの作成に必要なDDLを生成するために、「DDLの生成」プロシージャが使用されます。テンプレートとしてWC_SAMPLE_D_SEQを使用します。

1. デザイナで、「プロジェクト」→「BI Appsプロジェクト」→「順序」に移動します。

2. 「順序」フォルダを右クリックして、「新規順序」を選択します。

3. 名前を「<ディメンション名>_SEQ」に設定します。

4. 「ネイティブ順序」ラジオ・ボタンを選択します。

5. 「スキーマ」をDW_BIAPPS11Gに設定します。

6. 一般的に、名前の長さが30文字を超えないかぎり、ネイティブ順序名はODI名に一致する必要があります。30文字を超える場合は、この制限に合わせるために名前を短縮できます。これは、ROW_WID列にデータを移入するために作成されたデータベース・トリガーの名前です。

7. データベースの表を作成するDDLを生成します。注意: ODIのディメンションを手動で作成した場合、表と順序を両方作成するDDLを生成します。ディメンションをODIにインポートした場合、順序のみを作成するDDLを生成します。

SDEタスクとSILタスクの作成

カスタムのSDEおよびSILアダプタ・フォルダにSDEタスクとSILタスクを作成します。SDE_<製品ライン・コード>_SampleDimensionタスクおよびSIL_SampleDimensionタスクをテンプレートとして使用します。これらのタスクには、システム列にデータを移入するために必要なロジックが含まれます。最後に、これらのタスクのシナリオを生成します。

ロード計画ステップの追加

「3 SDE Dims X_CUSTOM_DIM <製品ライン・バージョン・コード>」ロード計画コンポーネントにロード計画ステップを追加します。

1. デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」→ SDE - <製品ライン・バージョン・コード>に移動して、「3 SDE Dims X_CUSTOM_DIM <製品ライン・バージョン・コード>」ロード計画コンポーネントをダブルクリックします。

2. 「ステップ」サブタブで、「X_CUSTOM_DIM」ステップを選択します。

3. 右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」を選択します。

4. 「シナリオ名」を指定して、「バージョン」を「-1」に設定し、タスク名に一致するように「ステップ名」を設定します。「再開タイプ」を「失敗したステップから再開」に設定します。

1.2.3.2.2 ファクトのデータストアとタスクのカスタマイズ

ファクトに関連するデータストアとタスクは、新しいディメンションを反映するように拡張する必要があります。W_<ファクト名>_FSとW_<ファクト名>_Fの両方のデータストアを拡張する必要があります。

ファクトのデータストアとタスクをカスタマイズするには:

1. 命名規則X_<名前>_IDに従うID列とデータ型VARCHAR2(80)を追加することにより、ファクト・ステージング・データストアを拡張します。

1. Oracle BI Applications Modelをあらかじめバージョニングしておく必要があります。

2. 「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ファクト・ステージ (サブモデル)」に移動して、「ファクト・ステージング表」をダブルクリックします。

3. 「列」サブタブで、「X_CUSTOM」列を選択します。

4. 緑の「+」記号をクリックして、「X_CUSTOM」列の下に列を追加します。

2. 命名規則X_<名前>_WIDに従うWID列とデータ型NUMBER(10)を追加することにより、「ファクト」データストアを拡張します。前述と同じステップに従って、ファクト・データストアに列を追加します。

3. 前に作成したカスタム・ディメンション表を参照する外部キー制約をファクト表に追加します。この外部キー制約により、生成されたロード計画にカスタムSILタスクが確実に含まれるようになります。生成されたロード計画にカスタムSDEタスクが含まれるのは、カスタムSILタスクのソースとして使用されるステージング表にデータを移入するためです。

1. 「ファクト」データストアにドリル・ダウンします。

2. 「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規の参照」を選択します。

3. 命名規則は、FK_<ファクト表>_<ディメンション表>です。同じディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します(たとえば、FK_WC_CUSTOM_F_WC_CUSTOM_D1)。「タイプ」は、「ユーザー参照」です。

4. 「表」ドロップダウン・リストから「カスタム・ディメンション」を選択します。

5. 「列」サブタブで、緑の「+」記号をクリックして、新しい列を追加します。

6. 「外部表」列の場合は、ファクト表でカスタムWID列を選択します。「プライマリ表」列の場合は、ディメンション表でROW_WID列を選択します。

4. X_<名前>_WID列で一意でないビットマップ索引を追加します。

1. 「ファクト」データストアにドリル・ダウンします。

2. 「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規キー」を選択します。

3. 命名規則は、<ファクト表>_F<n>です。これらの索引のそれぞれに数字の接尾辞を付けて列挙します(たとえば、WC_CUSTOM_F1)。

4. 「非一意索引」ラジオ・ボタンを選択します。

5. 「列」サブタブで、シャトル・ボタンを使用してWID列を追加します。

6. 「制御」サブタブで、「データベースで定義済」および「アクティブ」チェック・ボックスを選択します。

7. 「フレックスフィールド」サブタブで、索引タイプの値をQUERYに設定し、ビットマップ索引の値をYに設定します。

5. ファクトSDEタスクを変更します。ソース表の値をステージング表のカスタムX_<名前>_ID列に渡します。マッピング式に、必要な変換関数を組み込んで、データをVARCHAR2(80)形式に変換します。

6. ファクトSILタスクを変更します。カスタム・ディメンションからROW_WID値を取得するロジックを追加します。これは通常、次の方法のいずれかで実行されます。これらの2つの方法の間に大きな差はありません。

1. SQ一時インタフェースでソースとしてディメンションを追加します。ファクト表のID列、ディメンション表のINTEGRATION_ID列、およびファクトとディメンションのDATASOURCE_NUM_ID列に関して結合を行います。ディメンションがタイプIIのディメンションの場合、ディメンションの有効日間におけるファクトの正規日に関する範囲結合を含めます。「左の外部結合」として結合を構成します。出力としてROW_WID列を渡します。

2. メイン・インタフェースでルックアップとしてディメンションを追加します。ルックアップ結合は、ファクト表のID列、ディメンション表のINTEGRATION_ID列、およびファクトとディメンションのDATASOURCE_NUM_ID列に関して行われます。ディメンションがタイプIIのディメンションの場合、ディメンションの有効日間におけるファクトの正規日に関する範囲結合を含めます。「ルックアップ・タイプ」を「FROM句内のSQL左外部結合」として構成します。

7. メイン・インタフェースでカスタムのWID列にデータを移入するマッピング式において、NULL値を0にデフォルト設定する関数にディメンション表のROW_WID列を埋め込みます。たとえば、COALESCE(SQ_W_AP_HOLDS_FS.PURCHASE_ORG_WID,0)となります。

1.2.3.3 ファクトにDATE_WID列を追加する方法

このユースケースはファクトに標準のディメンションを追加する方法に似ていますが、このケースでは、日付ディメンションが使用されます。日付関連のディメンションは複数あり、それぞれ異なる方法(会計、企業など)および異なる間隔(日、週、月など)で日付を表します。

ファクトと日付ディメンション表間の結合は、日付固有のWID列上で行われます。この日付WID列は、YYYYMMDD形式で日付を表すスマート・キー値です。日付ディメンションのROW_WID列を解決するためにルックアップを実行する必要はありません。かわりに、ETLプロセスを通して日付列を渡して、この形式に変換します。

ファクト表ごとに1つずつ「正規の」日付固有のWID列があります。これは、様々な日付関連の計算を駆動するために使用されるプライマリ日付です。この列を識別する特定のメタデータはありませんが、ETLの有効日指定表のルックアップではこの列が使用され、RPDの様々な日付関連の式でもこの列が使用されます。パッケージ化されたファクト表はすべて、すでに識別された正規の日付を1つ持っています。カスタムのファクト表の作成時には、1つの日付WID列を正規日付として指定し、一貫して使用する必要があります。

ファクトにディメンションを追加する場合と同じステップに従います。ただし、次の変更点があります。既存の日付ディメンションを使用するので、カスタムのSDEを作成する必要はありません。

ファクトのデータストアとタスクのカスタマイズ

ファクトに関連するデータストアとタスクは、新しいディメンションを反映するように拡張する必要があります。W_<ファクト名>_FSとW_<ファクト名>_Fの両方のデータストアを拡張する必要があります。

1. 命名規則X_<名前>_DTに従うDT列を追加することにより、ファクト・ステージング・データストアを拡張します。この列には形式DATE(7)を設定する必要があります。

2. カスタムのDT列とDT_WID列を両方追加することによって、「ファクト」データストアを拡張します。これらは、命名規則X_<名前>_DTおよびX_<名前>_DT_WIDに従います。

3. 日付ディメンションに外部キー制約を追加します。同じ日付ディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します。

4. ファクトSDEタスクを変更します。ソース表の値をステージング表のカスタムX_<name>_DT列に渡します。必要な変換を適用して、データをDATE形式に変えます。

5. ファクトSILタスクを変更します。ステージング表のX_<名前>_DT値を、ファクト表の対応する列に渡します。メイン・インタフェースでカスタムのX_<名前>_DT_WID列にデータを移入するマッピング式において、DT_WID値を計算し、指定されたDTがNULLのときに0にデフォルト設定する関数にDT列を埋め込みます。たとえば、CALCULATE_DT_WID_DFLT(SQ_W_AP_HOLDS_FS.HOLD_DATE,0)となります。

1.3 カテゴリ2のカスタマイズ: 表の追加

カテゴリ2のカスタマイズでは、事前にパッケージされているアダプタを使用して、新しいファクト表またはディメンション表をOracle Business Analytics Warehouseに追加します。

この項の内容は次のとおりです。

- 第1.3.1項「表の新規作成について」

- 第1.3.2項「DATASOURCE_NUM_ID列について」

- 第1.3.3項「カスタマイズに関する追加情報」

- 第1.3.5項「Oracle Business Analytics Warehouseへの新しいファクト表の追加」

1.3.1 表の新規作成について

この項では、ソース表から、抽出済ではないデータがロードされる、完全に新しい表の作成について説明します。たとえば、新しい「プロジェクト」ディメンション表の作成が必要になる場合があります。この場合は、新しいディメンション表とステージング表および新しい抽出を作成して、ETLマッピングをロードします。

新しいカスタム表を作成する場合、接頭辞WC_を使用して、Oracleが提供する表とカスタム表を区別し、Oracleが今後同様の名前の表をリリースした場合のネーミングの競合を回避します。たとえば、「プロジェクト」ディメンションに対して、WC_PROJECT_DS表およびWC_PROJECT_D表を作成できます。

新しいディメンション表またはファクト表を作成するときには、それぞれのOracle Business Analytics Warehouse表に含まれる必須のシステム列を使用して、整合性を維持し、既存の表構造を参照できるようにします。新しい表を作成するときには、最初に表と索引をODIデザイナModels領域で定義する必要があります。Oracle Business Analytics Warehouseの宛先モデルは、「Oracle BI Applications」です。

1.3.1.1 主要な必須列について

カスタム・ステージング表に必要な列は次のとおりです。

- INTEGRATION_ID。 レコードの主キーまたは一意の識別子をソース表のように格納します。

- DATASOURCE_NUM_ID。 データの抽出元のデータ・ソースを格納します。

ディメンション表およびファクト表には、INTEGRATION_ID列とDATASOURCE_NUM_ID列の他に、次の列も必要です。

- ROW_WID。 ETLプロセスで生成される順序番号。Oracle Business Analytics Warehouseの一意の識別子として使用されます。

- ETL_PROC_WID。 ETLプロセス情報のIDを格納します。

1.3.2 DATASOURCE_NUM_ID列について

Oracle Business Analytics Warehouseのスキーマの表には、一意のユーザー・キーの一部としてDATASOURCE_NUM_IDが含まれています。通常、トランザクション・アプリケーションでは主キーが一意に維持されますが、複数のトランザクション・システム間で主キーが重複することは可能です。このデータをデータ・ウェアハウスにロードするときに問題が発生しないようにするために、ユーザー・キーの一部としてDATASOURCE_NUM_IDを含めると、一意性を維持できます。つまり、各データソースでこの列に異なる値が与えられている場合、それらの異なるソースの行を同じデータ・ウェアハウス表にロードできます。

1.3.3 カスタマイズに関する追加情報

この項では、Oracle Business Intelligence Applicationsのカスタマイズに関するその他の追加情報について説明します。

1.3.3.1 更新戦略について

新しいファクト表およびディメンション表をロードするときには、ソース側でカスタム・プロセスを設計して、新規または変更されたレコードが検出されるようにします。SDEプロセスは、変更されたデータ(新規または変更済)のみをロードするように設計する必要があります。データが増分プロセスなしにロードされた場合、それ以前にロードされたデータが再度更新され、余分なコストのかかるプロセスになります。たとえば、事前に構成済のSILマッピング内のロジックは、INTEGRATION_IDおよびDATASOURCE_NUM_IDに基づいてロード先の表をルックアップし、これらの組合せが存在する場合にはROW_WIDを返します。その場合、レコードが更新されます。ルックアップでNULLが返された場合は、レコードが挿入されます。場合によっては、指定した列とともに、ターゲット表に格納されている最終更新日も比較され、挿入または更新が決定されます。詳細は、事前に構成済のフォルダ内の同様のマッピングを参照してください。

1.3.3.2 索引と命名規則について

ステージング表には通常、索引は不要です。ステージング表に索引が必要かどうかは、慎重に判断してください。ETLでディメンションとファクトに使用されるすべての列に索引を作成します(たとえば、ディメンションとファクトのROW_WID、INTEGRATION_IDとDATASOURCE_NUM_ID、およびフラグ)。どの列または列の組合せのフィルタ条件が必要かを慎重に検討し、問合せのパフォーマンス向上につながる索引を定義します。参考用に事前に構成済のオブジェクトを検査します。新しく作成したすべての表に、WC_という名前を付けます。これにより、新しい表と事前構成済の表を見た目で区別できます。行ったカスタマイズの内容をきちんとドキュメントに残してください。データ・ウェアハウスをアップグレードするときに役立ちます。索引が決定したら、ODI Modelで登録します(詳細は、第1.5.2項「既存のファクト表またはディメンション表に索引を追加する方法」を参照)。

1.3.5 Oracle Business Analytics Warehouseへの新しいファクト表の追加

カスタム表は、事前構成済の表と区別できるように、WC_命名規則に従う必要があります。次の手順に従って、Oracle Business Analytics Warehouseに新しいファクト表を追加します。

新しいファクト表を追加するには:

1. カスタム・ファクト・データストアとタスクを作成します。「Oracle BI Applications – ファクト」モデルの下にWC_<ファクト名>_Fデータストアを作成します。「Oracle BI Applications – ファクト・ステージ」モデルの下にWC_<ファクト名>_FSデータストアを作成します。WC_SAMPLE_FSおよびWC_SAMPLE_Fデータストアをテンプレートとして使用します。これらのデータストアには、必須のすべてのシステム列が含まれます。
表が属する特定のサブモデルによって、表のメンテナンス動作が駆動されることに注意してください。たとえば、ファクト・ステージ・サブモデルの表は各ETLの実行時に常に切り捨てられますが、「ファクト」サブモデルの表は完全なETLの実行時にのみ切り捨てられます。

ODIでファクトを定義するには、データベースの表を作成するDDLを生成するか、またはデータベースの表を定義してBI Apps RKMによってその定義をODIにインポートします。RKMを使用する場合、インポートされた表は自動的に「その他」サブモデルに配置されるので、必要に応じて、ファクト・ステージング・サブモデルおよび「ファクト」サブモデルに移動する必要があります。また、ファクト表に対するOLAPタイプを「ファクト表」に設定することも必要になります。

ファクト表を手動で作成するには:

1. デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ファクト・ステージ (サブモデル)」に移動し、WC_SAMPLE_FSデータストアを右クリックして、「選択の複製」を選択します。

2. 新しいデータストアをダブルクリックして、その名前を変更します。「名前」と「リソース名」は、実際の表名に一致する必要があります。「別名」は、同じ値またはよりユーザー・フレンドリな値にすることができます。

3. 「列」サブタブで、すべての列を追加します。

4. 同じ手順を繰り返して、「ファクト」サブモデルの下にWC_SAMPLE_Fデータストアをコピーすることによって、ファクト表を作成します。

5. ファクト表に対して、OLAPタイプを「ファクト表」に設定します。

6. データベースの表を作成するDDLを生成します。

ODIにファクト表をインポートするには:

1. デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」に移動して、「Oracle BI Applicationsモデル」をダブルクリックします。

2. 「リバース・エンジニアリング」サブタブで、「LIST_OF_TABLE」オプションの下にインポート対象となる表を示します。複数の表をインポートする場合は、カンマ区切りリストで指定します。

3. 「リバース・エンジニアリング」をクリックします。ODIに表をインポートするセッションが開始されます。

4. 「リバース・エンジニアリング」プロセスによって、「その他」サブモデルにすべての表が配置されます。W_%_FS表をファクト・ステージ・サブモデルにドラッグ・アンド・ドロップし、W_%_F表を「ファクト」サブモデルにドラッグ・アンド・ドロップします。

5. 新しいファクト・データストアをダブルクリックして、OLAPタイプを「ファクト表」に設定します。

6. データベースの表を作成するDDLを生成します。

2. このファクトに関連付けられているすべてディメンション表に外部キー制約を追加します。この外部キー制約により、生成されたロード計画にディメンションSILタスクが確実に含まれるようになります。生成されたロード計画にディメンションSDEタスクが含まれるのは、ディメンションSILタスクのソースとして使用されるステージング表にデータを移入するためです。

1. 「ファクト」データストアにドリル・ダウンします。

2. 「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規の参照」を選択します。命名規則は、FK_<ファクト表>_<ディメンション表>です。同じディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します。たとえば、FK_WC_CUSTOM_F_WC_CUSTOM_D1となります。

3. 「タイプ」を「ユーザー参照」に設定し、「表」ドロップダウン・リストからディメンションを選択して、「列」サブタブで、右上の緑の「+」記号をクリックして新しい列を追加します。

4. 「外部表」列の場合は、ファクト表でカスタムWID列を選択します。「プライマリ表」列の場合は、ディメンション表でROW_WID列を選択します。

3. カスタムのSDEおよびSILアダプタ・フォルダにSDEタスクとSILタスクを作成します。SDE_<製品ライン・コード>_SampleFactタスクおよびSIL_SampleFactタスクをテンプレートとして使用します。これらのタスクには、システム列にデータを移入するために必要なロジックが含まれます。

4. 「3 SDE Facts X_CUSTOM_FG <製品ライン・バージョン・コード>」ロード計画コンポーネントにロード計画ステップを追加します。

1. デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」に移動します。

2. SDE - <製品ライン・バージョン・コード>に移動して、「3 SDE Facts X_CUSTOM_FG <製品ライン・バージョン・コード>」ロード計画コンポーネントをダブルクリックします。

3. 「X_CUSTOM_FG」ステップを選択します。

4. 右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」オプションを選択します。

5. 「シナリオ名」を指定して、「バージョン」を「-1」に設定し、「ステップ名」をタスク名に一致させます。「再開タイプ」を「失敗したステップから再開」に設定します。

5. 「3 SIL Facts X_CUSTOM_FG」ロード計画コンポーネントにロード計画ステップを追加します。

1. デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」に移動します。

2. SILに移動して、「3 SIL Facts X_CUSTOM_FG」ロード計画コンポーネントをダブルクリックします。

3. 「X_CUSTOM_FG」ステップを選択します。

4. 右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」オプションを選択します。

5. 「シナリオ名」を指定して、「バージョン」を「-1」に設定し、「ステップ名」をタスク名に一致させます。「再開タイプ」を「失敗したステップから再開」に設定します。

1.4 カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加

カテゴリ3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされているアダプタがないソースからデータをロードします。

この項の内容は次のとおりです。

- 第1.4.1項「標準的なディメンション表に新しいデータを行全体として追加する方法」

- 第1.4.2項「抽出の構成」

- 第1.4.3項「ロードの構成」

1.4.1 標準的なディメンション表に新しいデータを行全体として追加する方法

次の手順に従って、Oracle Business Analytics Warehouseの標準的なディメンション表に、新しいデータを行全体として追加します。

標準的なディメンション表に、新しいデータを行全体として追加するには:

1. ステージング表の既存の構造を特定して理解します。表構造については、『Oracle Business Analytics Warehouseデータ・モデル・リファレンス』を参照してください。システム以外の列ではNULL値を使用できます。

2. カスタムSDEインタフェースを作成して、この目的のために作成されたカスタム・フォルダのステージング表にデータをロードします。パフォーマンス上の理由により、ステージング表には、増分データ(ETLプロセスの最終更新プロセス以後に追加または変更された行)を移入する必要があります。

3. INTEGRATION_ID列に、レコードの一意の識別子を移入します。
INTEGRATION_IDとDATASOURCE_NUM_IDの組合せは一意です。INTEGRATION_ID列に、レコードの一意の識別子を移入します。INTEGRATION_IDとDATASOURCE_NUM_IDの組合せは一意です。

4. ステージング表にデータが移入されたら、標準的なSILインタフェースを使用してディメンション・ターゲット表に移入します。

1.4.2 抽出の構成

各アプリケーションには、特定のデータを特定のソースから抽出する事前にパッケージされたロジックがあります。この項では、Oracle Business Analytics Warehouseにロードする必要があるレコードのタイプおよびその必要がないレコードのタイプを処理することによって、レポートおよび非定型問合せに関するすべてのデータを取得する方法について説明します。項目は次のとおりです。

- 第1.4.2.1項「追加データの抽出」

- 第1.4.2.2項「ソース・ファイルのデリミタの設定」

1.4.2.1 追加データの抽出

Oracle Business Analytics Warehouseでは、抽出マッピングおよび抽出インタフェースを構成して、追加のソース・データに対応できます。たとえば、会社が地域に基づいて顧客情報を別々の表に分けている場合は、これらの表からデータを含めるように抽出インタフェースを設定する必要があります。

1.4.2.1.1 既存のソース表を使用した新しいデータの抽出

抽出インタフェースは通常、ソース表、ターゲット列で使用される式およびステージング表で構成されています。既存のインタフェースを使用して新しいデータを抽出する場合には、次のタスクを実行して、新しいデータを含めるように抽出インタフェースを変更する必要があります。

既存のインタフェースを変更して新しいデータを含めるには:

1. 既存のインタフェースを変更して、ソースから情報を抽出し、対応する拡張列に追加します。

2. 必要な変換を実行するようにターゲット表の式を変更します。

3. 変更内容を保存します。

4. シナリオを再生成します。

ステージング表内で、どのタイプの拡張列にデータをマッピングするかを決定する必要があります。抽出インタフェースを変更したら、対応するロード・インタフェース(SDEおよびSIL)も変更して、追加した拡張列がステージング表からターゲット・データ・ウェアハウス表までずっと接続されるようにする必要があります。

1.4.2.1.2 新しいソース表からのデータの抽出

抽出インタフェース(SQ_*命名規則に従います)は、リポジトリ内のソース固有のフォルダに配置されています。抽出インタフェースは、ソース・システムからのデータ抽出に使用します。これらの抽出インタフェースは、次の処理を実行するように構成できます。

- 新しいソース表からのデータの抽出

- 増分抽出ロジックの設定

1.4.2.2 ソース・ファイルのデリミタの設定

カンマ区切り(CSV)形式のソース・ファイルからデータをロードするときに、データにカンマ文字(,)が含まれている場合は、ソース・データに存在しないデリミタと呼ばれる適切な囲み文字を使用してソース・データを囲む必要があります。

注意: 別の方法として、自動的に適切な囲み文字でデータを囲むように、データ抽出プログラムを構成することもできます。

たとえば、CSVソース・データ・ファイルに次のデータが含まれているとします。

Months, Status
January, February, March, Active
April, May, June, Active

このデータを変更せずにロードした場合、ODIではMonthsの値として「January」をロードし、Statusの値として「February」をロードします。1つ目のレコードの残りのデータ(つまり、March, Active)はロードされません。

ODIでこのデータを正しくロードできるようにするには、次のようにMonthsフィールドのデータを二重引用符囲み文字(" ")で囲みます。

Months, Status
"January, February, March", Active
"April, May, June", Active

変更すると、データが正しくロードされるようになります。この例の1つ目のレコードでは、Monthsの値として「January, February, March」がロードされ、Statusの値として「Active」がロードされます。

ソース・ファイルのデリミタを設定するには:

1. ソース・データを含むCSVファイルを開きます。

2. あらかじめ選択した囲み文字(たとえば、("))でデータ・フィールドを囲みます。
ソース・データに存在しない囲み文字を選択する必要があります。囲み文字には一重引用符(')や二重引用符(")が一般的です。

3. CSVファイルを保存して閉じます。

4. ODIデザイナで、「モデル」ビューを表示し、「Oracle BI Applications」フォルダを展開します。
変更されたCSVファイルに関連付けられているデータ・ストアを特定します。変更したCSVファイルは、1つ以上のデータ・ストアに関連付けることができます。

5. 次に示すように、ODIデザイナで、囲み文字を使用するように、これらのデータ・ストアそれぞれのプロパティを変更します。

1. データ・ソースをダブルクリックします。これにより「データストア: <名前>」ダイアログが表示されます。

2. 「ファイル」タブを表示します。

3. 「テキスト・デリミタ」フィールドを使用して、ステップ2で使用した囲み文字を指定し、データを囲みます。

4. 「OK」をクリックして、変更内容を保存します。

これで、変更されたCSVファイルからデータをロードできます。

1.4.3 ロードの構成

この項では、Oracle Business Intelligence ApplicationsでOracle Business Analytics Warehouseにデータをロードする方法をカスタマイズする方法について説明します。

1.4.3.1 プライマリ抽出マッピングおよび削除マッピングのプロセスについて

プライマリ抽出セッションおよび削除セッションを有効にする前に、Oracle Business Analytics Warehouse内でのそれらの機能を理解することが重要です。プライマリ抽出マッピングおよび削除マッピングでは、分析システムでプライマリ抽出ステージング表を最新のOracle Business Analytics Warehouse表と比較することによって、ソース・システムから削除するレコードを決定できます。

プライマリ抽出マッピングは、ソース・システムから主キーの完全抽出を実行します。多くの行がこの抽出によって生成されますが、ソース表から抽出されるデータはキーIDおよびソースIDの情報のみです。プライマリ抽出マッピングは、これら2つの列を*_PE接尾辞でマークされたステージング表にロードします。

次の図は、抽出プロセスの開始例を示しています。これは、2日間のイベントのシーケンスを示しています。この期間に、ソース表の情報が変更されます。1日目、データは、ソース表から抽出され、Oracle Business Analytics Warehouse表にロードされます。2日目、販売オーダー番号3が削除され、新しい販売オーダーが受信され、2つの表間の販売オーダー情報の不一致が形成されます。

図1-3 抽出マッピングとロード・マッピング

図1-4は、2日目の情報が抽出され、ソースからOracle Business Analytics Warehouseにロードされたときに発生するプライマリ抽出プロセスおよび削除プロセスを示しています。最初の抽出で、レコード4がOracle Business Analytics Warehouseに渡されます。次に、プライマリ抽出マッピングを使用して、キーIDとソースIDがソース表から抽出され、プライマリ抽出ステージング表にロードされます。

抽出マッピングは、プライマリ抽出ステージング表のキーと最新のOracle Business Analytics Warehouse表のキーを比較します。これは、Oracle Business Analytics Warehouseには存在するが、ステージング表には存在しないレコード(前の例では、レコード3)を探し、Source Adapterの削除フラグをYに設定し、対応するレコードに削除というマークを付けます。

抽出マッピングは、ソースには追加されたが、Oracle Business Analytics Warehouseにはまだ存在していない新しいレコード(この場合はレコード4)もすべて検出します。ステージング表の情報に基づいて、販売注文番号3がOracle Business Analytics Warehouseから物理的に削除されます(図1-4を参照)。抽出マッピングおよびロード・マッピングを実行すると、ウェアハウスに新しい販売注文が追加されます。

図1-4 プライマリ抽出マッピングと削除マッピング

1.4.3.2 プライマリ抽出マッピングおよび削除マッピングを使用した作業について

プライマリ抽出マッピング(*_Primary)および削除マッピング(*_IdentifyDeleteおよび*_Softdelete)は、ソース・システムから物理的に削除されたレコードを識別する際に重要な役割を果たします。ただし、プライマリ抽出マッピングおよび削除マッピングを無効または削除できる場合があります。たとえば、ソース・システムのデータベースから削除され、別のデータベースにアーカイブされたレコードをOracle Business Analytics Warehouseに保持する場合です。

削除マッピングでは、ソースIDとキーIDを使用して、削除されたデータが識別されるため、複数のソース・システムを使用している場合には、SQL問合せ文を変更して、削除マッピングで適切なソースIDが使用されていることを確認する必要があります。プライマリ抽出マッピングおよび削除マッピングに加えて、ロード・マッピングの削除フラグの構成でも、レコードの削除の処理方法を決定できます。

データの抽出と削除は、次の方法で管理できます。

- ソースがアーカイブしたレコードの構成の削除

- 特定のソースからのレコードの削除

- 削除セッションおよびプライマリ抽出セッションの有効化

- レコード削除フラグの構成

- レコード却下フラグの構成

1.4.3.2.1 ソースがアーカイブしたレコードの構成の削除

一部のソースは、レコードを別のデータベースにアーカイブして、メイン・データベースに現在の情報のみを保持します。削除マッピングを有効にしている場合は、Oracle Business Analytics Warehouseの削除マッピングを再構成して、アーカイブされたデータを保持する必要があります。

ソースがアーカイブしたレコードをOracle Business Analytics Warehouseで保持するには、LAST_ARCHIVE_DATEパラメータの値を、アーカイブの日付を反映するように適切に設定してください。削除マッピングは、アーカイブされたレコードに削除済というマークを付けません。抽出マッピングおよび削除マッピングの詳細は、第1.4.3.2項「プライマリ抽出マッピングおよび削除マッピングを使用した作業について」を参照してください。

1.5 ストアド・ルックアップのカスタマイズおよび索引の追加

この項では、Oracle Business Intelligence Applicationsのカスタマイズの3つのすべてのカテゴリに適用されるその他の情報について説明します。この項の内容は次のとおりです。

- 第1.5.1項「ストアド・ルックアップについて」

- 第1.5.2項「既存のファクト表またはディメンション表に索引を追加する方法」

1.5.1 ストアド・ルックアップについて

この項では、コード・ルックアップとディメンション・キーについて説明します。

1.5.1.1 ディメンション・キーの解決について

デフォルトでは、ディメンション・キーの解決は、Oracle Business Analytics Warehouseのロード・マッピングで実行されます。ロード・インタフェースは、事前にパッケージされた再利用可能なルックアップ変換を使用して、事前にパッケージされたディメンション・キーの解決を実現します。この項では、ディメンション・キーのルックアップ方法および解決方法について説明します。

ディメンション・キーの解決には、一般に2種類の方法が使用されます。1つ目の方法は、最も使用される方法であり、ディメンション・キーへのルックアップを実行することです。2つ目の方法は、ファクト・ロード・マッピングに直接ディメンション・キーを提供することです。

1.5.1.1.1 ルックアップを使用したディメンション・キーの解決

ロード・インタフェースにデータベース結合によってディメンション・キーが提供されない場合には、ロード・マッピングでディメンション表内へのルックアップを実行します。ロード・マッピングでは、事前にパッケージされたルックアップ・インタフェースを使用してこの処理を実行します。ディメンション・キーをルックアップするには、ロード・インタフェースでINTEGRATION_ID、DATASOURCE_NUM_IDおよびルックアップ日付を使用します。次の表はこれらのポートについて説明しています。

表1-1 ロード・マッピングのディメンション・キー・ルックアップで使用される列

ポート

説明

INTEGRATION ID

ソース・システム内でディメンション・エンティティを一意に識別します。ファクト表のSource Adapterにあるトランザクションで形成されます。

DATASOURCE_NUM_ID

ソース・システムのインスタンスの一意の識別子。

ルックアップ日付

取引のプライマリ日付(受領日や販売日など)。

タイプIIの緩やかに変化するディメンションが有効な場合、ロード・マッピングでは、ディメンション・レコードの更新ごとに一意の有効日が使用されます。ディメンション・キーのルックアップ時には、ファクトのプライマリ日付または「正規の」日付を使用して適切なディメンション・キーが解決されます。有効日の範囲は、ディメンション・レコードの有効期間を指定します。タイプIIの緩やかに変化するディメンションであるため、同じエンティティで、有効日の異なる複数のレコードをディメンション表内に持つことができます。この有効日の範囲は、ディメンション内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。

ロード・インタフェース・ルックアップに必要な4つの列(INTEGRATION ID、DATASOURCE_NUM_IDおよびルックアップ日付(EFFECTIVE_FROM_DTとEFFECTIVE_TO_DATE))が用意されています。このルックアップで、ROW_WID (ディメンションの主キー)が対応するファクト表のWID列(ファクト表の外部キー)に出力されます。

1.5.2 既存のファクト表またはディメンション表に索引を追加する方法

Oracle Business Analytics Warehouseのディメンション表とファクト表では、次の2種類の索引を使用します。

- ETL索引
ETL索引は、一意/バイナリ・ツリー索引に使用されます。

- 問合せ索引
問合せ索引は、非一意/ビット・マップ索引に使用されます。

既存のファクト表またはディメンション表に索引を追加するには:

1. ODIデザイナで、「モデル」ビューを表示し、「Oracle BI Applications」フォルダを展開します。

2. 必要に応じて、「ファクト」または「ディメンション」ノードを展開します。

3. 索引を作成する表を展開します。

4. 「制約」ノードを右クリックして、「キーの挿入」を選択し、「キー: 新規」ダイアログを表示します。

5. 「説明」タブを表示します。

6. 「代替キー」ラジオ・ボタンを選択し、「名前」フィールドの索引の名前を更新します。

7. 「列」タブを表示します。

8. 索引を作成する列を選択します。

9. 「フレックスフィールド」タブを表示します。

10. この設定を使用して、次のように索引タイプを指定します。

- 「問合せ」タイプの索引(デフォルト)の場合、一意の索引に対して「代替キー」として索引を定義し、非一意の索引に対して「非一意索引」として索引を定義します。

- 「ETL」タイプの索引の場合、INDEX_TYPEパラメータのチェック・ボックスの選択を解除し、値を「ETL」に設定します。また、IS_BITMAPパラメータの値を「N」に設定し、一意の索引に対して「代替キー」として索引を定義し、非一意の索引に対して「非一意索引」として索引を定義します。

11. 変更内容を保存します。

1.6 RPDのトリミング

Oracle BI Applicationsリリース11.1.1.8.1は、すべてのBI ApplicationsモジュールおよびOperational Planning Applicationsに対するプロジェクトを含む完全なRPDファイルを提供しています。BIサーバーには、この完全なRPDがデプロイされます。自分のデプロイメントに関係するプロジェクトのみを含むように、RPDをトリミングできます。RPDのトリミングはオプションですが、BIサーバーの起動プロセスが高速化され、パッチの適用も迅速化されます。

RPDをトリミングする手順は、デプロイメントの状態によって変わります。

- RPDが自分のデプロイメント向けにカスタマイズされていない場合は、所属する組織が購入した製品に対するプロジェクトを抽出します。マージを実行する必要はありません。手順は、第1.6.1項「完全なRPDからのプロジェクトの抽出」を参照してください。

- RPDが自分のデプロイメント向けにカスタマイズされている場合は、リリース11.1.1.8.1に対する完全な(提供されている)RPDから適用可能なプロジェクトを抽出した上で、そのRPDを、カスタマイズ済のリリース11.1.1.8.1 RPDとマージします。手順は、第1.6.1項「完全なRPDからのプロジェクトの抽出」を参照してください。

1.6.1 完全なRPDからのプロジェクトの抽出

次の手順に従って、完全なRPDからプロジェクトを抽出します。このプロセスの最終的な結果が、トリミングされたRPDになります。

購入した製品に対するプロジェクトをRPDから抽出するには:

1. BI Administration Toolがインストールされているコンピュータで、コマンド・ウィンドウを開きます。

2. WindowsにOracle BI EEをインストールした場合、bi-init.cmdを実行し、ご使用のOracleインスタンスに対して初期化されたコマンド・プロンプトを起動します。このユーティリティは次の場所にあります。

<MiddlewareHome>\instances\instance<n>\bifoundation\OracleBIApplication\coreapplication\setup

BIクライアント・インストーラを使用してBI Administration Toolをインストールした場合、bi_init.batを実行し、ご使用のOracleインスタンスに対して初期化されたコマンド・プロンプトを起動します。このファイルは次の場所にあります。

<Oracle BI Home>\oraclebi\orahome\bifoundation\server\bin

3. コマンド・プロンプト・ウィンドウで、次の説明に従って、ExtractProjectsを実行します。

- WindowsにOracle BI EEをインストールした場合、ExtractProjects.exeは<Oracle Home for BI>\bifoundation\server\binに配置されています。

- BIクライアント・インストーラを使用してBI Administration Toolをインストールした場合、ExtractProjects.exeは<Oracle BI Home>\oraclebi\orahome\bifoundation\server\binに配置されています。

次のコマンドのいずれかを実行します。

単一のプロンプトを抽出する場合:

ExtractProjects -B input_rpd -O output_rpd -I "project_name"

複数のプロンプトを抽出する場合:

ExtractProjects -B input_rpd -O output_rpd -I "project_name1" -I "project_name2"-I "project_name3" (and so on)

ここで、

input_rpdは、完全な(提供されている)リリース11.1.1.8.1 RPDの名前とパスであり、ここからプロジェクトを抽出します(OracleBIApps.rpdなど)。

output_rpdは、抽出されたプロジェクトを使用して作成するRPDの名前とパスです(OracleBIAppsTrimmed.rpdなど)。

project_nameは、抽出するRPDプロジェクトの名前です。

RPDに対する暗号化パスワードの入力が求められます(input_rpd)。

11.1.1.8.1 RPD内のプロジェクトのリストには、次のものが含まれます。

- Financial Analytics Fusion Edition

- Human Resources Analytics Fusion Edition

- Marketing Analytics Fusion Edition

- Partner Analytics Fusion Edition

- Project Analytics Fusion Edition

- Sales Analytics Fusion Edition

- Supply Chain and Order Management Analytics Fusion Edition

- Student Information Analytics

- Service Analytics

- Price Analytics

- Manufacturing Analytics

- Operational Planning

- DataLineage_Project

注意: RPDには、前述のもの以外のプロジェクトも含まれています。これらのプロジェクトは、将来のコンテンツ配信やアップグレード・サポートのために含まれています。このリリースで使用可能なBI Applicationsを確認するには、Oracle BI Applicationsリリース11.1.1.8.1のシステム要件とサポートされているプラットフォームに関する項(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)を参照してください。

4. トリミングされたRPDを保存して名前を変更します。このRPDがトリミング済のRPDであることがわかるような名前にしてください(たとえば、OracleBIAppsTrimmed.rpd)。

1.6.1.1 ディメンション・キーの解決について

デフォルトでは、ディメンション・キーの解決は、Oracle Business Analytics Warehouseのロード・マッピングで実行されます。ロード・インタフェースは、事前にパッケージされた再利用可能なルックアップ変換を使用して、事前にパッケージされたディメンション・キーの解決を実現します。この項では、ディメンション・キーのルックアップ方法および解決方法について説明します。

ディメンション・キーの解決には、一般に2種類の方法が使用されます。1つ目の方法は、最も使用される方法であり、ディメンション・キーへのルックアップを実行することです。2つ目の方法は、ファクト・ロード・マッピングに直接ディメンション・キーを提供することです。

1.6.1.1.1 ルックアップを使用したディメンション・キーの解決

ロード・インタフェースにデータベース結合によってディメンション・キーが提供されない場合には、ロード・マッピングでディメンション表内へのルックアップを実行します。ロード・マッピングでは、事前にパッケージされたルックアップ・インタフェースを使用してこの処理を実行します。ディメンション・キーをルックアップするには、ロード・インタフェースでINTEGRATION_ID、DATASOURCE_NUM_IDおよびルックアップ日付を使用します。次の表はこれらのポートについて説明しています。

表1-2 ロード・マッピングのディメンション・キー・ルックアップで使用される列

ポート

説明

INTEGRATION ID

ソース・システム内でディメンション・エンティティを一意に識別します。ファクト表のSource Adapterにあるトランザクションで形成されます。

DATASOURCE_NUM_ID

ソース・システムのインスタンスの一意の識別子。

ルックアップ日付

取引のプライマリ日付(受領日や販売日など)。

タイプIIの緩やかに変化するディメンションが有効な場合、ロード・マッピングでは、ディメンション・レコードの更新ごとに一意の有効日が使用されます。ディメンション・キーのルックアップ時には、ファクトのプライマリ日付または「正規の」日付を使用して適切なディメンション・キーが解決されます。有効日の範囲は、ディメンション・レコードの有効期間を指定します。タイプIIの緩やかに変化するディメンションであるため、同じエンティティで、有効日の異なる複数のレコードをディメンション表内に持つことができます。この有効日の範囲は、ディメンション内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。

ロード・インタフェース・ルックアップに必要な4つの列(INTEGRATION ID、DATASOURCE_NUM_IDおよびルックアップ日付(EFFECTIVE_FROM_DTとEFFECTIVE_TO_DATE))が用意されています。このルックアップで、ROW_WID (ディメンションの主キー)が対応するファクト表のWID列(ファクト表の外部キー)に出力されます。

次の手順は、RPDをカスタマイズした後、RPDをトリミングしている場合にのみ実行してください。

リポジトリをマージするには:

1. Oracle BI Administration Toolで、第1.6.1項「完全なRPDからのプロジェクトの抽出」の手順で作成したトリミング済のOracle BI RPD(OracleBIAppsTrimmed.rpdなど)をオフラインモードで開きます。

2. メニュー・バーで、「ファイル」をクリックし、次に「マージ」をクリックします。

3. 「元のリポジトリの選択」ダイアログ・ボックスで、リポジトリOracleBIApps.rpdを選択します。これは完全なRPDです。

4. 元のリポジトリのパスワードを入力して、「OK」をクリックします。

5. 「修正済リポジトリ」フィールドで「選択」をクリックします。「変更済リポジトリの選択」ダイアログ・ボックスが開きます。
「変更済リポジトリの選択」ダイアログが開きます。

6. RPDファイルに対して行ったカスタマイズ内容を含むリポジトリを選択します(たとえば、OracleBIAppsCustom.rpd)。

7. 「開く」をクリックし、以前にカスタマイズしたRPDファイルのパスワードを入力して、「OK」をクリックします。

8. 「デシジョン」ドロップダウン・リストで、リポジトリの変更に関して実行するアクションを選択するか、デフォルトのアクションを受け入れます。

9. 空の「デシジョン」フィールドを含む後続の行を探すには、「デシジョン」のヘッダー・セルをクリックします。「デシジョン」フィールドのすべての行に値が設定されると、「マージ」ボタンが有効になります。

10. 「マージ」をクリックします。
マージが正常に完了すると、メッセージが表示されます。

11. メニュー・バーで、「ファイル」をクリックし、次に「名前を付けて保存」をクリックします。新しい名前(OracleBIAppsFinal.rpdなど)を使用して現在のリポジトリを保存します。

2 複数言語のサポートについて

この章では、Oracle BI Applicationsにおける複数言語のサポートについて説明します。

この章の内容は次のとおりです。

- 第2.1項「複数言語サポートの概要」

- 第2.2項「擬似翻訳について」

- 第2.3項「Oracle BI Applicationsのドメインについて」

- 第2.4項「ディメンション翻訳表について」

2.1 複数言語サポートの概要

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値を持つレコードにフィルタ処理されます。

2.2 擬似翻訳について

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と異なるので、擬似翻訳レコードを識別できます。

表2-1 擬似翻訳レコードの例

INTEGRATION_ID

NAME

LANGUAGE_CODE

SRC_LANGUAGE_CODE

ABC

Executive

US

US

ABC

Executive

IT

IT

ABC

Executive

SP

US

2.3 Oracle BI Applicationsのドメインについて

ドメインとは、リレーショナル・データベースの表の列の、使用可能な一意値のことを指しています。トランザクション・システムでは、ドメインはしばしば値リスト(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プロセスの概要を示しています。

図2-1 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.4 ディメンション翻訳表について

第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ドメインプロセスを示しています。

図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メタデータの文字列のローカライゼーションを追加する方法に関する項を参照してください。

3 Oracle Business Intelligenceのデプロイメントのローカライズ

この章では、Oracle Business Intelligence Applicationsのローカライズの概念と手法について説明します。Oracle Business Intelligenceは、ユーザーが優先言語とロケールのプリファレンスを動的に変更できるように設計されています。この項では、英語以外の1つ以上の言語環境でデプロイメントするようにOracle BI Applicationsを構成する方法を説明します。

この章の内容は次のとおりです。

- 第3.1項「Oracle BI EE用翻訳表のメンテナンスのプロセス」

- 第3.2項「Presentation Services文字列の翻訳について」

- 第3.3項「Analyticsアプリケーションのデフォルト通貨の変更」

3.1 Oracle BI EE用翻訳表のメンテナンスのプロセス

Oracle Business Intelligenceの「プレゼンテーション」レイヤーでは、任意の列名に対して複数の翻訳がサポートされています。Oracle BI Answersを操作したり、ダッシュボードをレンダリングする際に、ユーザーはそれぞれのローカル言語でレポートに文字列を表示します。たとえば、英語を話すユーザーやフランス語を話すユーザーは、それぞれのローカル言語でレポートに文字列を表示します。Oracle Business Intelligenceでは翻訳が必要なアプリケーション文字列は、次の2種類があります。

- メタデータ
メタデータ文字列は、AnalyticsがOracle Business Intelligenceリポジトリに作成したオブジェクトで、サブジェクト領域、メトリックおよびディメンションなどがあります。

- プレゼンテーション・サービス
Presentation Servicesオブジェクトは、エンド・ユーザーが作成したオブジェクトで、レポート、ダッシュボードおよびページなどがあります。Presentation Services文字列の翻訳は、XMLキャプション・ファイルに格納されます。これらの文字列にアクセスして翻訳を変更する方法の詳細は、『Oracle Business Intelligence Presentation Services管理ガイド』を参照してください。

この処理には次の作業が含まれます。

- 第3.1.1項「英語以外のロケールに対するOracle Business Intelligenceシード・データのアップグレード」

- 第3.1.2項「顧客のメタデータ文字列の外部化」

- 第3.1.3項「W_LOCALIZED_STRING_G表へのカスタム翻訳の追加」

3.1.1 英語以外のロケールに対するOracle Business Intelligenceシード・データのアップグレード

デプロイメントのOracle Business Intelligenceデータが、英語以外の言語で表示される場合、次の手順を実行する必要があります。

1. 翻訳表(W_LOCALIZED_STRING_G)および対応する索引の作成を確認します(第3.1.1.1項「翻訳表(W_LOCALIZED_STRING_G)および対応する索引の確認」を参照)。

2. ロケール・シード・データをW_LOCALIZED_STRING_G表にインポートします(第3.1.1.2項「翻訳表(W_LOCALIZED_STRING_G)へのロケール・シード・データのインポート」を参照)。

3. セッション・レベルで初期化ブロックを作成してLOCALE変数を設定します。
たとえば、次の手順を実行します。

1. Oracle BI EE Administration Toolで、「管理」→「変数」を選択し、「変数マネージャ」ダイアログを開きます。

2. 「アクション」メニューから、「新規」→「セッション」→「初期化ブロック」を選択します。

3. 「セッション変数初期化ブロック」ダイアログで、ブロックの名前を入力します。たとえば、「LOCAL_INIT_BLOCK」と入力します。

4. 「データ・ソースの編集」ボタンをクリックします。

5. 「デフォルトの初期化文字列」ボックスで、SQL初期化文字列を入力します。たとえば、次のように入力します。
select 'VALUEOF(NQ_SESSION.WEBLANGUAGE)' from VALUEOF(OLAPTBO).DUAL

6. 「接続プール」フィールドの隣の「参照」をクリックし、適切な接続プールを選択します。たとえば、"Oracle EBS OLTP"、"Oracle EBS OLTP InitBlocks Connection Pool"を選択します。

7. 「変数マネージャ」ダイアログで、「セッション」→「変数」→「非システム」に移動します。

8. LOCAL変数をダブルクリックして、「セッション変数」ダイアログを開きます。

9. 「セッション変数」ダイアログで、「初期化ブロック」リストを使用して、新しい初期化ブロック(LOCAL_INIT_BLOCKなど)を選択します。

3.1.1.1 翻訳表(W_LOCALIZED_STRING_G)および対応する索引の確認

翻訳表(W_LOCALIZED_STRING_G)および対応する索引を確認するには:

1. Oracle Business Analytics WarehouseにW_LOCALIZED_STRING_G表が含まれていることを確認します。

2. DACで次の索引の定義を検索し、それらをOracle Business Analytics Warehouseに手動で作成します。

- W_LOCAL_STRING_G_U1

- W_LOCAL_STRING_G_P1

- W_LOCAL_STRING_G_M1

- W_LOCAL_STRING_G_M2

注意: 表内のデータを誤って複製することを防ぐため、次の項においてロケール・シード・データをインポートする前に、これらの索引をW_LOCALIZED_STRING_Gに追加することをお薦めします。

3.1.1.2 翻訳表(W_LOCALIZED_STRING_G)へのロケール・シード・データのインポート

使用されているプライマリ言語が英語ではない場合、(使用する言語の数に応じて)追加のロケール・シード・データをインポートする必要がある場合があります。この処理は、ユーザーがWebクライアントで使用する各言語に対して、一度ずつ実行する必要があります。

注意

- この手順はBI管理者のみが実行する必要があります。

- この作業を実行するには、dataimpユーティリティが必要です。これは、32ビット版オペレーティング・システムでのみ使用できます。

- Oracle Business Intelligence Applicationのインストール中に、ORACLE_HOME\biapps\seeddataという名前のディレクトリが作成されます。ここには、言語ごとにサブディレクトリがあります。各言語サブディレクトリ内部に、.datファイル(インポート対象データ)と.inpファイル(インポートを制御するWHERE句)があります。

ロケール・シード・データを翻訳表(W_LOCALIZED_STRING_G)にインポートするには:

1. コマンド・ウィンドウを開き、ORACLE_HOME\biapps\seeddata\binディレクトリに移動します。

2. 次の接続パラメータをデータベース環境に適した値に置換してから、手順3のインポート・コマンドを実行します。

- UserName

- Password

- ODBCDataSource

- DatabaseOwner

3. 次のインポート・コマンドを実行します。

ORACLE_HOME\biapps\seeddata\Bin\dataimp /u $UserName /p $Password /c "$ODBCDataSource" /d $DatabaseOwner /f ORACLE_HOME\biapps\seeddata\l_<XX>\analytics_seed_<XXX>.dat /w y /q 100 /h Log /x f /i ORACLE_HOME\biapps\seeddata\l_<XX>\metadata_upgrade_<XXX>_<DBPlatform>.inp /l metadata_upgrade_<XXX>.log

注意:

XXは2文字のOracle Business Intelligence言語コード(fr、it)に置換し、XXXは3文字のSiebel Systemsコード(FRA、ITA)に置換します。

4. ロケール・シード・データを翻訳表(W_LOCALIZED_STRING_G)にインポートする作業が終了したら、Oracle BI Administration Toolを使用してOracle BI Repositoryの初期化ブロックを構成し、この表が存在するデータベースに接続します。

注意:

Unicode接続は、Unicodeをサポートしていないデータベースにアクセスするために使用できます。

3.1.2 顧客のメタデータ文字列の外部化

メタデータ文字列は、Oracle BI Serverによりデータベース表からロードされます。Oracle Business Intelligenceアプリケーションの場合、この表はデータ・ウェアハウスにあるW_LOCALIZED_STRING_Gです。「Externalize Metadata Strings」という初期化ブロックによりサーバーの文字列がロードされます。この初期化ブロックが正常に実行することを確認するためのテストを実行することをお薦めします。翻訳表の例を、表3-1に示します。

表3-1 W_LOCALIZED_STRING_G翻訳表の例

MSG_NUM

MSG_TEXT

LANG_ID

CN_Customer_Satisfaction

Customer Satisfaction

ENU

CN_Customer_Satisfaction

Kundenzufriedenheit

DEU

CN_Customer_Satisfaction

Satisfação do cliente

PTB

デフォルトでは、Oracle Business Intelligenceリポジトリは英語でのみ実行するように構成されています。他の言語でデプロイするには、次の手順に従ってメタデータ文字列を外部化する必要があります。

メタデータ文字列をOracle Business Intelligenceリポジトリで外部化するには:

1. Oracle BI Serverを停止します。

2. Oracle BI Administration Toolをオフライン・モードで使用して、OracleBIAnalyticsApps.rpdを開きます。

3. 「プレゼンテーション」レイヤー全体を選択し、マウスを右クリックしてメニューを表示します。

- ポップアップ・メニューから、「表示名の外部化」を選択します。(次回「プレゼンテーション」レイヤーを右クリックした際、このオプションの横にチェック・マークが表示されます。)

- 「プレゼンテーション」レイヤーの選択を解除します。

注意:

「表示名の外部化」を選択すると、すべてのメタデータ文字列がデータ・ウェアハウス内のW_LOCALIZED_STRING_G表から読み取られます。

4. 「物理」レイヤーで、「外部化されたメタデータ文字列」データベース・アイコンを選択します。ツリーを開きます。

5. 「内部システム接続プール」をダブルクリックします。
「接続プール」ダイアログの「一般」タブで、「データ・ソース名」フィールドがデータ・ウェアハウスを指すようにします。

6. 「OK」をクリックしてOracle BI Administration Toolを終了します。

7. Oracle BI Serverを再起動します。

3.1.3 W_LOCALIZED_STRING_G表へのカスタム翻訳の追加

カスタム・オブジェクトをメタデータに追加し、これらのオブジェクトを外部化することを選択した場合(オブジェクトを右クリックして「表示名の外部化」オプションを選択)、Oracle BI ServerはW_LOCALIZED_STRING_G表で翻訳(母国語を含む)を検索します。

表示名を外部化しない場合、次の手順を実行する必要はありません。

注意:

「プレゼンテーション」レイヤーのカスタム・オブジェクトは、メタデータの母国語(新しいオブジェクトの追加対象言語)でのみ表示されます。

3.1.3.1 Analyticsメタデータに対する文字列翻訳の追加

次に示す手順では、Oracle Business Intelligenceメタデータの文字列翻訳をW_LOCALIZED_STRING_G表に追加する方法について説明します。この作業は、任意データベース管理ツールとOracle BI Administration Toolで実行します。

Analyticsメタデータの文字列翻訳を追加するには:

1. データベース管理ツールを起動し、データ・ウェアハウス・データベースに接続します。

2. W_LOCALIZED_STRING_Gという名前の表を問合せます。次の手順4から8で示すように、新しいレコードをこの表に追加します。

3. 次の手順を実行して、Oracle BI Administration Toolからメッセージ・キーを取得します。

- Oracle BI Administration Toolで、「プレゼンテーション」レイヤーの新しいメタデータ・オブジェクトを右クリックして、メニューから「プロパティ」を選択します。

- メッセージ・キーが「カスタム表示名」の下のダイアログに表示されます。メッセージ・キーは、CN_で始まる部分です。
たとえば、「プレゼンテーション」レイヤーで「パイプライン」カタログ・ディレクトリをダブルクリックします。「カスタム表示名」は、Valueof(NQ_SESSION.CN_Pipeline)です。CN_Pipelineがメッセージ・キーになります。

4. 新しいレコードにデプロイメント言語を入力します

5. 必須のメッセージ・タイプ(たとえば、Metadata、FINS_Metadata)を入力します。

6. メッセージ・レベルAnalyticsNewを選択し、次の手順を実行します。

- 「メッセージ・テキスト」列で、オブジェクトの翻訳を追加します。

- 「翻訳」列および「アクティブ」列のフラグを選択します(「はい」に設定)。

- 「エラー・メッセージ: #」列を0に設定します。

7. 必須のメッセージ機能(たとえば、HMF、FIN)を入力します。

8. 新しいメタデータ・オブジェクト文字列ごとに、手順3から7を繰り返します。

9. データベース管理ツールを終了し、Oracle BI Serverを再起動します。

3.2 Presentation Services文字列の翻訳について

Presentation Servicesオブジェクトの翻訳(レポートやページの名前など)は、ORACLE_HOME\biapps\catalog\res\web\l_<Language Abbreviation>\Captionsディレクトリで使用可能なxxxCaptions.xmlファイルに格納されます。複数言語デプロイメント・モードでは、レポートや新しいダッシュボード・ページなどのPresentation Servicesオブジェクトを追加する場合は、適切な翻訳も追加する必要があります。Catalog Managerツールを使用して翻訳を追加します。このユーティリティを使用する方法の詳細は、『Oracle Business Intelligence Presentation Services管理ガイド』を参照してください。

3.3 Analyticsアプリケーションのデフォルト通貨の変更

Oracle Business Intelligence Applicationsでは、ドル記号が金額のデフォルト記号として表示される場合があります。この動作を変更するには、次の手順を使用してcurrencies.xmlファイルを編集する必要があります。currencies.xmlファイルは、次のディレクトリにあります。

- Windowsの場合:

ORACLE_HOME\bifoundation\web\display\currencies.xml

- UNIXの場合:

ORACLE_HOME/bifoundation/web/display/currencies.xml

Analyticsアプリケーションのデフォルト通貨を変更するには:

1. テキスト・エディタでcurrencies.xmlファイルを開きます。

2. ウェアハウスのデフォルトで通貨タグ(tag="int:wrhs")を検索します。

<Currency tag="int:wrhs" type="international" symbol="$" format="$#" digits="2"
displayMessage="kmsgCurrencySiebelWarehouse">
<negative tag="minus" format="-$#" />
</Currency>

3. ウェアハウスのデフォルトにおける記号、フォーマット、桁、負に関連する情報を、デフォルトとして使用する通貨タグの情報で置換します。
たとえば、日本円をデフォルトにする場合、ウェアハウスのデフォルト通貨タグの内容を、日本円通貨のタグ(tag="loc:ja-JP")の値に置換します。

<Currency tag="loc:ja-JP" type="local" symbol="¥" locale="ja-JP" format="$#"
digits="0">
<negative tag="minus" format="-$#" />
</Currency>

作業を終了すると、日本円のデフォルト・ウェアハウス通貨タグは、次のようになります。

<Currency tag="int:wrhs" type="international" symbol="¥" format="$#" digits="0"
displayMessage="kmsgCurrencySiebelWarehouse">
<negative tag="minus" format="-$#" />
</Currency>

4. currencies.xmlファイルを保存して閉じます。

4 Oracle Business Analytics Warehouseの命名規則

この章には、Oracle Business Analytics Warehouseの表と列のタイプ、および使用される命名規則に関する情報が記載されています。

注意:

この章には、Oracle Business Analytics Warehouseのデータベースの表と列で使用される命名規則が記載されています。この情報は、Oracle Business Intelligenceのリポジトリ内のオブジェクトには適用されません。

この章の内容は次のとおりです。

- 第4.1項「Oracle Business Analytics Warehouseの表の命名規則」

- 第4.2項「Oracle Business Analytics Warehouseの表のタイプ」

- 第4.3項「Oracle Business Analytics Warehouseの内部表」

- 第4.4項「Oracle Business Analytics Warehouseの列の標準接頭辞」

- 第4.5項「Oracle Business Analytics Warehouseの列の標準接尾辞」

- 第4.6項「Oracle Business Analytics Warehouseの表のシステム列」

- 第4.7項「システム列での複数通貨のサポート」

- 第4.8項「Oracle Business Analytics Warehouseのプライマリ・データ値」

- 第4.8項「Oracle Business Analytics Warehouseのプライマリ・データ値」

- 第4.9項「Oracle Business Analytics Warehouseでの複数言語のサポートについて」

- 第4.10項「Oracle Business Analytics Warehouseでの通貨のプリファレンス」

4.1 Oracle Business Analytics Warehouseの表の命名規則

Oracle Business Analytics Warehouseの表では、表4-1に示すように、接頭辞_名前_接尾辞の3つの要素からなる命名規則が使用されます。

表4-1 Oracle Business Analytics Data Warehouseの表の命名規則

要素

意味

表のタイプ

接頭辞

Oracle Business Intelligence固有のデータ・ウェアハウス・アプリケーションの表であることを示します。

W_ = ウェアハウス

名前

一意の表の名前です。

すべての表。

接尾辞

表のタイプを示します。

_A = 集計
_D = ディメンション
_DEL = 削除
_DH = ディメンション階層
_DHL = ディメンション・ヘルパー
_DHLS = ディメンション・ヘルパーのステージング
_DHS = ディメンション階層のステージング
_DS = ディメンションのステージング
_F = ファクト
_FS = ファクトのステージング
_G、_GS = 内部
_H = ヘルパー
_HS = ヘルパーのステージング
_MD = ミニ・ディメンション
_PE = プライマリ抽出
_PS = 永続化されたステージング
_RH = 行にフラット化された階層
_TL = 翻訳ステージング(複数言語をサポート)
_TMP = ステージング前またはステージング後の一時表
_UD = バインドなしのディメンション
_WS = Usage Acceleratorのステージング

4.2 Oracle Business Analytics Warehouseの表のタイプ

表4-2は、Oracle Business Analytics Warehouseで使用される表のタイプの一覧を示しています。

表4-2 Oracle Business Analytics Warehouseで使用される表のタイプ

表のタイプ

説明

集計表(_A)

合計(集計された)データが含まれます。

ディメンション表(_D)

スター分析のディメンション。

削除表(_DEL)

ソース・システムから物理的に削除されており、データ・ウェアハウスから削除されたことを示すフラグを付ける必要のあるエンティティのIDを格納する表です。

削除表には_DELと_PEの2つのタイプがあることに注意してください。_PEの表のタイプについては、この表のプライマリ抽出表(_PE)の行を参照してください。

ディメンション階層表(_DH)

ディメンションの階層構造を格納する表です。

ディメンション・ヘルパー表(_DHL)

2つの結合されたディメンション表の間の多対多の関係を格納する表です。

ディメンション・ヘルパーのステージング表(_DHLS)

2つの結合されたディメンション表の間の多対多の関係を格納するステージング表です。

ディメンション階層のステージング表
(_DHS)

最終的な抽出、変換、ロード(ETL)の変換処理を経ていないディメンションの階層構造を格納するステージング表です。

ディメンション・ステージング表(_DS)

最終的なETLの変換処理を経ていないディメンションに関する情報の保持に使用される表です。

ファクト表(_F)

ディメンションによって分析されるメトリックが含まれます。

ファクト・ステージング表(_FS)

最終的なETLの変換処理を経ていないディメンションによって分析されるメトリックの保持に使用されるステージング表です。

内部表(_G、_GS)

ETL処理をサポートするために使用される汎用的な表です。

ヘルパー表(_H)

ファクト・レコードとディメンション・レコードの多対多の関係をサポートするため、ファクト表とディメンション表の間に挿入されます。

ヘルパー・ステージング表(_HS)

最終的なETLの変換処理を経ていないヘルパー表に関する情報の保持に使用される表です。

ミニ・ディメンション表(_MD)

親ディメンションで最も頻繁に問合せが行われる属性の組合せが含まれます。データベースはこれらの小さな表を結合してファクト表にします。

プライマリ抽出表(_PE)

ソフト削除機能をサポートするために使用される表です。この表には、ソース・システムのすべての主キー列(統合ID列)が含まれます。削除イベントが発生すると、プライマリ抽出表内の以前に抽出されたデータとソースからの全体抽出とが比較され、Siebelアプリケーションで物理削除が行われたかどうかが判定されます。ソフト削除機能はデフォルトでは無効になっています。したがって、ソフト削除機能を有効にするまでプライマリ抽出表にデータは移入されません。

削除表には_DELと_PEの2つのタイプがあることに注意してください。_DELの表のタイプについては、この表の削除表(_DEL)の行を参照してください。

永続化されたステージング表(_PS)

同一のソース表から複数回データ抽出を行う場合のソースとなる表です。

これらの表では、複数のターゲット・オブジェクトで必要となる共通の変換処理の一部が実行されます。また、これらの表によって、複数のターゲット・オブジェクトで必要となるウェアハウスで利用可能なフォームのソース・オブジェクトが簡素化されます。これらの表は、データ・ウェアハウスの存続期間中に切り捨てられることはありません。切り捨てられるのはフル・ロードの実行時のみであり、したがって全体を通じてデータが永続化されます。

行にフラット化された階層表(_RH)

階層内のノードを祖先と子の関係のセット(すべての親レベルの親子関係)によって記録する表です。

翻訳ステージング表(_TL)

名前および説明をOracle BI Applicationsでサポートされる言語で保存する表です。

ステージング前またはステージング後の一時表(_TMP)

ETL処理の一環として汎用的なステージング表(表のタイプが_DSおよび_FS)にデータを適合させるために使用される、ソース固有の表です。これらの表には、適合処理の一環として作成される中間結果が格納されます。

バインドなしのディメンション(_UD)

トランザクション・データベースのデータにはバインドされていないものの、Oracle Business Analytics Warehouseではバインドされたデータとして扱う必要のある情報が格納される表です。

Usage Acceleratorのステージング表(_WS)

ETL変換処理で必要な列が含まれる表です。

4.2.1 Oracle Business Analytics Warehouseの集計表

データ・ウェアハウスの主な使用法の1つに、日付や販売地域などの指定されたディメンションに関してファクト・データを合計するという処理があります。この合計処理をオンデマンドで実行すると、リソースを大量に消費し、応答時間が低下します。Oracle Business Analytics Warehouseでは、これらの合計の一部を事前に計算し、集計表に格納します。Oracle Business Analytics Warehouseでは、集計表には_Aという接尾辞が付きます。

4.2.2 Oracle Business Analytics Warehouseのディメンション・クラス表

クラス表とは、似たビジネス属性を持つ複数の論理エンティティを格納できる1つの物理表です。各種の論理ディメンションはタイプやカテゴリなどのセパレータ列によって区切られます。W_XACT_TYPE_Dはディメンション・クラス表の一例です。販売注文タイプ、販売請求タイプ、購入注文タイプなどの異なるトランザクション・タイプを同一の物理表に格納できます。

既存の物理表にさらにトランザクション・タイプを追加できます。これにより、新しい物理表の設計や維持にかかる工数を削減できます。ただし、その際には、特定の論理ディメンション固有の属性は物理表内に定義できないことを考慮する必要があります。また、特定の論理ディメンションに多数のレコードがある場合は、その特定の論理エンティティ用に個別の物理表を定義するのが設計手法として適切である可能性があります。

4.2.3 Oracle Business Analytics Warehouseのディメンション表

ロード処理時に、個々のディメンション表に一意の数値キー(ROW_WID)が生成されます。このキーは、各ディメンション表とそれに対応するファクト表を結合するのに使用されます。また、このキーは、ディメンションとそれに関連する階層表または拡張表を結合するのにも使用されます。Oracle Business Analytics Warehouseの表のROW_WID列は数値です。各ディメンション表で、ROW_WIDのゼロの値は未指定として予約されています。ファクト表内の指定されたレコードに対応する1つ以上のディメンションが未指定になっている場合、そのレコード内の対応するキー・フィールドはゼロに設定されます。

4.2.4 ビジネス・ロール・ベースのフラグを持つディメンション表

この設計アプローチは、エンティティが論理的に同一であるものの、ビジネス・プロセスでそれらが別のロールとして関与する場合に使用されます。一例をあげると、従業員は人事のビジネス・プロセスでは従業員として関与し、販売プロセスでは販売担当者として関与し、受取勘定プロセスでは徴収者として関与し、購入プロセスでは購入者として関与するという場合が考えられます。しかし、これらは同一の従業員です。このような論理エンティティのために、対応する物理表(たとえばW_EMPLOYEE_D)に、ビジネスにおいてレコードが異なる役割で関与することを記述するためのフラグが用意されています。

プレゼンテーション・レイヤーの構成時に、フラグベースのフィルタによって同一の物理表を個別の論理エンティティとして使用できます。たとえば、特定のスター・スキーマで購入者をディメンションとして使用する必要がある場合、購入者フラグがYであるというフィルタを指定して従業員表を使用できます。

4.2.5 Oracle Business Analytics Warehouseのファクト表

それぞれのファクト表には、その表を様々なディメンション表にリンクするための1つ以上の数値外部キー列が含まれています。

4.2.6 Oracle Business Analytics Warehouseのヘルパー表

ヘルパー表は、単純なディメンション・スキーマでは解決できない複雑な問題を解決するために、Oracle Business Analytics Warehouseによって使用されます。

典型的なディメンション・スキーマでは、ファクト・レコードとディメンション・レコードが多対1の関係で結合されます。ファクト・レコードとディメンション・レコードの多対多の関係をサポートするには、ファクト表とディメンション表の間にヘルパー表が挿入されます。

ヘルパー表には、ファクトとディメンションのそれぞれのキーの組合せに関するレコードが複数格納されます。これによって、指定されたディメンション値に対応するファクトを問合せで取得できます。一連のディメンション値に対応するファクト・レコードを集計する場合、多対多の関係によってオーバーラップが発生し、二重にカウントされる状況が発生する可能性があることを念頭に置く必要があります。

時折、ディメンション内の親の値のみを指定して、その親の子に関連付けられているファクトを問い合せる必要が生じます(たとえば、あるマネージャの販売ファクトをそのマネージャの部下の販売ファクトを含めて計算する場合)。このような状況が発生する場合は、すべての親と子のディメンション・キーの組合せに対応した複数のレコードが格納されたヘルパー表をファクトとディメンションの間に挿入します。これにより、ディメンション内の1つの親を指定するだけで、そのすべての子に関する問合せを実行できます。

4.2.7 Oracle Business Analytics Warehouseの階層表

ディメンション表の中には、各レコードを編成するための階層を持つものがあります。この階層情報は個別の表に格納され、対応するディメンション表内のそれぞれのレコードに対して1つのレコードが存在します。この情報により、レポートの中で階層をドリル・アップおよびドリル・ダウンすることができます。

Oracle Business Analytics Warehouseには2つの階層のタイプがあります。一定のレベル数を持つ構造化された階層と、親子関係による階層です。構造化された階層では、それぞれの子は一定の数の親を持ち、子が親になることはできないため、モデル化が簡単です。2つ目の階層である非構造化親子関係は、どの子レコードも親になる可能性があり、親子関係のレベル数は固定されないため、モデル化が簡単ではありません。階層表には_DHという接尾辞が付きます。

4.2.8 Oracle Business Analytics Warehouseのミニ・ディメンション表

ミニ・ディメンション表には、親ディメンションで最も頻繁に問合せが行われる属性の組合せが含まれます。これによって、データベースでファクト表を大きな親ディメンションに結合する必要がなくなり、より小さな表をファクト表に結合できるようになるため、問合せのパフォーマンスが向上します。

表4-3は、Oracle Business Analytics Warehouseのミニ・ディメンション表の一覧を示しています。

表4-3 Oracle Business Analytics Warehouseのミニ・ディメンション表

表名

親ディメンション

W_RESPONSE_MD

親はW_RESPONSE_D

W_AGREE_MD

親はW_AGREE_D

W_ASSET_MD

親はW_ASSET_D

W_OPTY_MD

親はW_OPTY_D

W_ORDER_MD

親はW_ORDER_D

W_QUOTE_MD

親はW_QUOTE_D

W_SRVREQ_MD

親はW_SRVREQ_D

4.2.9 Oracle Business Analytics Warehouseのステージング表

ステージング表は、主にトランザクション・データベースからの増分データをステージングするのに使用されます。ETL処理が実行されると、ステージング表は切り捨てられ、その後で変更取得データが移入されます。最初のETLの完全ロードの実行時には、これらのステージング表に過去一定期間のソース・データ・セット全体が格納されますが、以降のリフレッシュETLの実行時には格納されるデータ量ははるかに少なくなります。

このステージング・データ(値の翻訳、計算、通貨換算のリスト)は変換され、ディメンションおよびファクトのステージング表にロードされます。通常、これらの表は、<表名>_DSまたは<表名>_FSのようにタグが付加されます。Usage Acceleratorのステージング表は、WS_<表名>のようにタグが付加されます。

ステージング表の構造はソース・データの構造からは独立しており、データ・ウェアハウスの表の構造に似ています。この類似点によって、ステージング表をトランザクション・データベースのソースとデータ・ウェアハウスのターゲット表との間のインタフェース表としても使用できます。

4.2.10 Oracle Business Analytics Warehouseの翻訳表

翻訳表は、Oracle Business Analytics Warehouseでサポートされる各言語で名前と説明を格納することによって複数言語のサポートを提供します。翻訳表には次の2つのタイプがあります。

- %_CODE列に格納される値に関連付けられた複数言語サポートを提供するドメイン表

- ディメンション用の複数言語サポートを提供する表

ドメイン、およびそれらに関連付けられた翻訳値は、W_DOMAIN_MEMBER_LKP_TLという名前の1つの表に格納されます。ドメインでは実現できない複数言語サポートを必要とする各ディメンションには、_TL表が関連付けられます。これらの表とディメンション表との間には1対多の関係があります。ディメンション表の個々のレコードに対しては、関連付けられた翻訳表内に複数のレコードが存在します(サポートされる言語ごとに1つのレコード)。

4.3 Oracle Business Analytics Warehouseの内部表

内部表は、主にETLマッピングでデータ変換やETLの実行制御を行うために使用されます。これらの表に対してエンド・ユーザーが問い合せることはありません。表4-4はこれらの表に関する説明です。

表4-4 Oracle Business Analytics Warehouseの内部表

名前

目的

場所

W_DUAL_G

日のディメンションのレコードを生成するのに使用されます。

データ・ウェアハウス

W_COSTLST_G

コスト・リストを格納します。

データ・ウェアハウス

W_DOMAIN_MEMBER_G

増分変更をW_DOMAIN_MEMBER_GおよびW_DOMAIN_MEMBER_G_TLに移入するためのステージング表です。

データ・ウェアハウス

W_DOMAIN_MEMBER_G_TL

W_DOMAIN_MEMBER_G_TL内のドメイン・メンバー・コードに対応するインストール済の各言語の翻訳値を格納します。

データ・ウェアハウス

W_DOMAIN_MEMBER_GS

すべてのドメイン・メンバーとインストール済の各言語の値を格納します。

データ・ウェアハウス

W_DOMAIN_MEMBER_MAP_G

ETLの実行時に、ソース・ドメイン・コードの値に基づいてターゲット・ドメイン・コードを解決するのに使用されます。

データ・ウェアハウス

W_DOMAIN_MEMBER_MAP_NUM_G

ETLの実行時に、ソースの数値範囲内での数値比較に基づいてターゲット・ドメイン・コードを解決するのに使用されます。

データ・ウェアハウス

W_EXCH_RATE_G

為替レートを格納します。

データ・ウェアハウス

W_LANGUAGES_G

データ・ウェアハウスでサポートされる言語翻訳を格納します。これは、ETLの実行時に、擬似翻訳という手法によって存在しない翻訳レコードをベース言語から生成するのに使用されます。

データ・ウェアハウス

W_LOCALIZED_STRING_G

データ・ウェアハウス

W_LOV_EXCPT_G

ETL処理で例外を検出した値のリストのタイプに関する値のリストを格納します。

データ・ウェアハウス

W_UOM_CONVERSION_G

「単位: 自」および「単位: 至」のコードのリスト、およびそれらの変換レートを格納します。

データ・ウェアハウス

4.4 Oracle Business Analytics Warehouseの列の標準接頭辞

Oracle Business Analytics Warehouseでは、表4-5に示すように、特定の値を格納する必要があるフィールドであることを示すために標準の接頭辞が使用されます。

表4-5 列の標準接頭辞

接頭辞

説明

表のタイプ

W_

Oracle BI Applicationsの標準、または標準化された値を格納するのに使用されます。たとえば、W_%_CODE (ウェアハウスの適合ドメイン)およびW_TYPE、W_INSERT_DT (ウェアハウスに挿入される日付レコード)がこれに該当します。

_A

_D

_F

4.5 Oracle Business Analytics Warehouseの列の標準接尾辞

Oracle Business Analytics Warehouseでは、表4-6に示すように、特定の値を格納する必要があるフィールドであることを示すために接尾辞が使用されます。

表4-6 列の標準接尾辞

接尾辞

説明

表のタイプ

_CODE

コード・フィールド。(特にドメイン・コードで使用されます。)

_D、_DS、_FS、_G、_GS

_DT

日付フィールド。

_D、_DS、_FS、_G、_DHL、
_DHLS

_ID

対応する_F表の_WID列に対応します。

_FS、_DS

_FLG

インジケータまたはフラグ。

_D、_DHL、_DS、_FS、_F、_G、_DHLS

_WID

Oracle Business Intelligenceによって生成される、ディメンション表とファクト表をリンクするための識別子です(ROW_WIDを除く)。

_F、_A、_DHL

_NAME

属性に関連付けられている名前をデータ・ウェアハウスでサポートされるすべての言語で格納するための、複数言語サポート列です。

_TL

_DESCR

属性に関連付けられている説明をデータ・ウェアハウスでサポートされるすべての言語で格納するための、複数言語サポート列です。

_TL

4.6 Oracle Business Analytics Warehouseの表のシステム列

Oracle Business Analytics Warehouseの表にはシステム・フィールドが含まれています。これらのシステム・フィールドには自動的にデータが移入されます。ユーザーはそれらを修正しないようにする必要があります。表4-7は、データ・ウェアハウスのディメンション表で使用されるシステム列の一覧を示しています。

表4-7 データ・ウェアハウスの表で使用されるシステム列

システム列

説明

ROW_WID

レコードを一意に識別するためのサロゲート・キーです。

CREATED_BY_WID

ソース・システムでレコードを作成したユーザーを指定するW_USER_Dディメンションに対する外部キーです。

CHANGED_BY_WID

ソース・システムで最後にレコードを変更したユーザーを指定するW_USER_Dディメンションに対する外部キーです。

CREATED_ON_DT

ソース・システムでレコードが最初に作成されたときの日付と時刻です。

CHANGED_ON_DT

ソース・システムでレコードが最後に変更されたときの日付と時刻です。

AUX1_CHANGED_ON_DT

システム・フィールドです。この列は、現在の表のソースとして機能する補助表のレコードの最終変更日時を特定します。

AUX2_CHANGED_ON_DT

システム・フィールドです。この列は、現在の表のソースとして機能する補助表のレコードの最終変更日時を特定します。

AUX3_CHANGED_ON_DT

システム・フィールドです。この列は、現在の表のソースとして機能する補助表のレコードの最終変更日時を特定します。

AUX4_CHANGED_ON_DT

システム・フィールドです。この列は、現在の表のソースとして機能する補助表のレコードの最終変更日時を特定します。

DELETE_FLG

このフラグは、ソース・システムにおけるレコードの削除ステータスを示します。値がYの場合、レコードはソース・システムから削除されており、データ・ウェアハウスから論理的に削除されたことを示します。値がNの場合、レコードはアクティブであることを示します。

W_INSERT_DT

データ・ウェアハウスの表にレコードが挿入された日付が格納されます。

W_UPDATE_DT

データ・ウェアハウスの表でレコードが最後に更新された日付が格納されます。

DATASOURCE_NUM_ID

データの抽出元となったソース・システムの一意の識別子です。ソースにさかのぼってデータをトレースできるようにするため、それぞれのソース・インスタンスに対して一意のソースIDを定義することをお薦めします。

ETL_PROC_WID

システム・フィールドです。この列は、このデータを作成または更新するのに使用された個別のETL処理を識別するための一意の識別子です。

INTEGRATION_ID

ソース・システムにおけるディメンション・エンティティまたはファクト・エンティティの一意の識別子です。コンポジット・キーの場合、この列の値は複数の要素の連結によって構成されることがあります。

TENANT_ID

マルチテナント環境でテナントを識別するための一意の識別子です。この列は通常、アプリケーション・サービス・プロバイダ(ASP)/ソフトウェア・アズ・ア・サービス(SaaS)のモデルで使用されます。

X_CUSTOM

顧客拡張において汎用的なフィールドとして使用される列です。

CURRENT_FLG

これは、ディメンション・エンティティの現在の状態を表すことを目的として、ディメンションのレコードに「Y」のマーキングを行うフラグです。このフラグは通常、タイプIIの緩やかに変化するディメンションにおいて重要です。なぜなら、タイプIIの状況ではレコード数が非常に多くなる傾向にあるからです。

EFFECTIVE_FROM_DT

この列には、ディメンション・レコードの有効期間の最初の日付が格納されます。値は、Oracle BI Applicationsによって割り当てられるか、またはソースから抽出されます。

EFFECTIVE_TO_DT

この列には、ディメンション・レコードの有効期間の最後の日付が格納されます。値は、Oracle BI Applicationsによって割り当てられるか、またはソースから抽出されます。

SRC_EFF_FROM_DT

この列には、ソース・システムにおけるソース・レコードの有効期間の最初の日付が格納されます。値はソースから抽出されます(利用可能な場合)。

STC_EFF_TO_DT

この列には、ソース・システムにおけるソース・レコードの有効期間の最後の日付が格納されます。値はソースから抽出されます(利用可能な場合)。

4.7 システム列での複数通貨のサポート

表4-8は、関連するシステム列の通貨コードとレートの一覧です。

表4-8 関連するシステム列の通貨コードとレート

システム列

説明

DOC_CURR_CODE

ソース・システムでドキュメントが作成されたときの通貨のコードです。

LOC_CURR_CODE

ドキュメントが作成された金融機関で通常使用されるレポート用通貨コードです。

GRP_CURR_CODE

ドキュメントが作成された企業グループまたは組織グループで主に使用されるグループのレポート用通貨コードです。

LOC_EXCHANGE_RATE

ドキュメントの通貨コードから現地通貨コードへの通貨換算レートです。

GLOBAL1_EXCHANGE_RATE

ドキュメントの通貨コードからGlobal1通貨コードへの通貨換算レートです。

GLOBAL2_EXCHANGE_RATE

ドキュメントの通貨コードからGLOBAL2通貨コードへの通貨換算レートです。

GLOBAL3_EXCHANGE_RATE

ドキュメントの通貨コードからGLOBAL3通貨コードへの通貨換算レートです。

PROJ_CURR_CODE

プロジェクト分析で使用される、OLTPシステムのプロジェクト通貨に対応するコードです。

4.8 Oracle Business Analytics Warehouseのプライマリ・データ値

様々なディメンションが相互に1対多および多対多の関係を持つことが可能です。ただし、このような関係は分析で問題を引き起こす場合があります。たとえば、1つの商談が多くの営業担当に関連付けられ、1人の営業担当が多くの商談に関連付けられる可能性があります。分析に商談と営業担当の両方を含める場合、それぞれの営業担当に関連付けられている商談の数をカウントして、同じ商談を何度もカウントしてしまうことによってカウント数が正確でなくなる可能性があります。

このような問題を回避するため、Oracle Business Analytics Warehouseでは、関係の「多」の部分に関してプライマリ・メンバーが考慮されます。1つの商談が多くの営業担当に関連付けられる例では、プライマリ営業担当のみが商談に関連付けられます。商談と営業担当の両方が含まれる分析では、個々の商談は1回のみ現れ、商談のカウントは正しい結果を返します。

このルールにはいくつかの重要な例外があります。個人のスター・スキーマでは、連絡先とアカウントとの間の多対多の関係がサポートされます。したがって、個人のスター・スキーマに対してアカウントと連絡先の両方を問い合せると、アカウントと連絡先のすべての組合せが返されます。商談-競合会社のスター・スキーマでは、商談と競合会社のアカウントとの間で多対多の関係がサポートされます。キャンペーン-商談のスター・スキーマでは、キャンペーンと商談との間で多対多の関係がサポートされます。その他のスター・スキーマでは、問合せによって返されるのは特定の連絡先のプライマリ・アカウントのみです。

4.9 Oracle Business Analytics Warehouseでの複数言語のサポートについて

Oracle BI Applicationsでは、Oracle BI Enterprise Editionのダッシュボードとレポートで公開されるメタデータ・レベルのオブジェクトおよびデータに関して複数言語サポートを提供しています。これにより、ユーザーは優先言語に翻訳されたレコードを参照できます。複数言語のサポートの詳細は、第2章「複数言語のサポートについて」を参照してください。

4.10 Oracle Business Analytics Warehouseでの通貨のプリファレンス

通貨の設定の詳細は、機能設定マネージャの次のタスクを参照してください。共通エリアおよびディメンションの構成\グローバル通貨の構成。

Oracle Business Analytics Warehouseでは、次の通貨のプリファレンスをサポートします。

- 契約通貨。契約額を定義するのに使用される通貨です。この通貨はプロジェクト分析のみで使用されます。

- CRM通貨。Fusion CRMアプリケーションで定義されるCRM企業通貨です。この通貨はCRM分析アプリケーションのみで使用されます。

- ドキュメント通貨。トランザクションが実行され、関連ドキュメントが作成される際に使用される通貨です。

- グローバル通貨。Oracle Business Analytics Warehouseでは、最大3つのグループ通貨が格納されます。異なる通貨によるグローバル・レポートを可能にするには、これらのグループ通貨を事前に構成する必要があります。為替レートは表W_EXCH_RATE_Gに格納されます。

- 現地通貨。トランザクションが発生する法的エンティティの会計通貨です。

- プロジェクト通貨。プロジェクト管理で使用される通貨です。これは機能通貨とは異なる場合があります。これはプロジェクト分析のみに適用されます。

5 Oracle Business IntelligenceのEndeca Discoveryオプション

この章では、Oracle EndecaとOracle BI Applicationsを組み合せて設定および使用する方法について説明します。

この章の内容は次のとおりです。

- 第5.1項「はじめに」

- 第5.2項「EndecaとOracle BI Applicationsの統合の設定」

- 第5.3項「Oracle EndecaとOracle BI Applicationsを組み合せて設定する際のタスク」

- 第5.4項「ODIパッケージ、インタフェースおよびプロシージャの設計の概要」

- 第5.5項「サンプル・アプリケーションのデプロイ」

- 第5.6項「カスタムBIアプリケーションのセキュリティ・マネージャの適用」

- 第5.7項「トラブルシューティング」

5.1 はじめに

Oracle BI ApplicationsはオプションでOracle Endeca Information Discoveryとともに使用できます。これにより、Oracle Endeca Information DiscoveryはOracle BI Applicationsのデータを使用してデータを視覚化できます。Oracle Endeca Information Discoveryは、構造化されたソース、非構造化ソースの両方の情報を分析するための エンタープライズ・ディスカバリ・プラットフォームです。タグ・クラウドなど、様々な多くの方法でデータを検索し視覚化する機能を備えています。

5.2 EndecaとOracle BI Applicationsの統合の設定

この項では、Oracle EndecaとOracle BI Applicationsを組み合せて設定する方法について説明します。

Oracle EndecaとOracle BI Applicationsを組み合せて設定するための手順のリスト

EndecaをインストールしてOracle BI Applicationsとの統合を設定するには、次のタスクを順に実行する必要があります。それぞれのハイレベル・タスクを詳細な手順に分割した説明は次の項に記載されています。

1. Oracle Endeca Server 7.6.0をインストールします。Endeca Serverの要件およびインストールの詳細は、『Oracle Endeca Serverインストール・ガイド』を参照してください。提供されているすべてのパッチをインストールしてください。

2. Endeca 3.1 Studioをインストールします。Studioの要件およびインストールの詳細は、『Oracle Endeca Information Discovery Studioインストール・ガイド』を参照してください。提供されているパッチをインストールしてください。

3. Oracle Data Integrator (ODI) StudioでODIトポロジを設定し、Oracle Business Intelligence Enterprise Editionをソースとして、Endeca Serverをターゲットとして含めます。また、必要に応じてアクセスを設定します。第5.3.3項「設定手順: Oracle BIおよびEndecaのためのODI接続の設定」の説明を参照してください。

4. ODIのシナリオを個別に実行するか、またはODIロード計画を実行してデータをロードします。第5.3.4項「設定手順: データのロード」の説明を参照してください。

5. Endeca Studioアプリケーションを新規作成し、サンプル・アプリケーションをデプロイします。第5.3.5項「設定手順: Endecaアプリケーションの新規作成」の説明を参照してください。

5.3 Oracle EndecaとOracle BI Applicationsを組み合せて設定する際のタスク

この項では、Oracle EndecaとOracle BI Applicationsを組み合せて設定する際の詳細なタスクについて説明します。この項の内容は次のとおりです。

- 第5.3.1項「設定手順: Oracle Endeca Serverのインストール」

- 第5.3.2項「設定手順: Endeca 3.1 Studioのインストール」

- 第5.3.3項「設定手順: Oracle BIおよびEndecaのためのODI接続の設定」

- 第5.3.4項「設定手順: データのロード」

- 第5.3.5項「設定手順: Endecaアプリケーションの新規作成」

注意: この項のタスクは、第5.2項「EndecaとOracle BI Applicationsの統合の設定」で説明されている順序で実行する必要があります。

5.3.1 設定手順: Oracle Endeca Serverのインストール

Endeca Serverの要件およびインストールの詳細は、『Oracle Endeca Serverインストール・ガイド』を参照してください。提供されているすべてのパッチをインストールしてください。オプションで、次に説明されているEndeca Serverの最適化手順を実行することもできます。

推奨されるデータ・サイズ

スレッド数が6以下に構成されているEndeca Serverのハードウェアでは、次のようにデータ・サイズを制限することをお薦めします。

1. 属性数が300、行数が1,000,000を超えないようにデータを制限します。

2. 含まれる属性が少ないほど、同じ時間でロードされる行数は多くなります(1時間当たりの属性数は最大3億)。

3. 処理能力が高いほど、一定時間にロードできる行数は多くなります。

Endecaデータ・ドメイン・プロファイルの作成によるCPUコア数の最適化

Endeca Serverのデータ・ドメイン・プロファイルにはnumComputeThreadsというプロパティがあり、2に設定されています。これは2つのCPUコアを意味します。データ・ドメインの新規作成時に新しいデータ・ドメイン・プロファイルを作成して、サーバーで利用可能なCPUコアの数に応じてnumComputeThreadsの値を設定します。このプロパティの設定、およびendeca-cmdユーティリティを使用したドメインの作成の詳細は、『Oracle Endeca Server管理者ガイド』の「Endeca Serverコマンド・リファレンス」の章を参照してください。

新しいデータ・ドメイン・プロファイルを作成した後、Endecaロード計画またはシナリオを実行するときに新しいプロファイルの名前をODIパラメータENDECA_DATADOMAIN_PROFILEに設定します。Endecaロード計画およびシナリオの実行の詳細は、第5.3.4項「設定手順: データのロード」を参照してください。

データ・ドメインの無効化、有効化または削除

データ収集時には、データ・ドメインのメモリー使用量が最も高くなり、メモリーを解放しません。ドメインは、オペレーティング・システムに対する他のメモリー要求の領域を空けるために、必要に応じてメモリーをページングする傾向にあります。メモリー使用量が利用可能な最大値に近づいた場合、各データ・ドメインを無効にしてから有効にすることによってメモリーの要求量を削減できます。

サーバー上で次のendeca-cmdコマンドを実行することによって、既存のドメインを無効にしてから再度有効にできます。endeca-cmdコマンドライン・ユーティリティの場所は、$MWHOME\EndecaServer7.6.1\endeca-cmdです。

- データ・ドメインを無効にする: endeca-cmd disable-dd <data-domain>

- データ・ドメインを有効にする: endeca-cmd enable-dd <data-domain>

既存のデータを保持する場合や、一定時間データ・ドメインをオンラインにしておく必要がない場合は、データ・ドメインを無効のままにしておくことができます。データ・ドメインが不要になった場合は、削除してリソースを解放することもできます。バックアップは実行されないため、データ・ドメインを削除すると復元できません。シェル・スクリプトまたはバッチ・ファイル・スクリプトを使用して、複数のデータ・ドメインの無効化、有効化および削除を実行できます。

5.3.2 設定手順: Endeca 3.1 Studioのインストール

Endeca 3.1 Studioをインストールします。Studioの要件およびインストールの詳細は、『Oracle Endeca Information Discovery Studioインストール・ガイド』を参照してください。提供されているパッチをインストールしてください。

5.3.3 設定手順: Oracle BIおよびEndecaのためのODI接続の設定

この手順では、BI Applicationsのデータ・ウェアハウスでEndeca ETLをサポートするために、Oracle Data Integrator (ODI)内にソースおよびターゲットのサーバー定義を作成します。また、必要なEndecaビューXMLファイル用の定義も作成します。

Oracle BI Enterprise Editionのソースの作成

EndecaとOracle BI Applicationsを統合する場合、EndecaはEndecaロード計画を使用してOracle Business Analytics Warehouseのデータをソースにします。その際、データ型、列名、属性グループ名などのBI Serverメタデータを使用してEndecaスキーマがロードされる前に、OBAWデータの非正規化が行われ、それがEndecaデータ・ドメインにロードされます。この統合をサポートするため、ODIリポジトリのメタデータにODIデータ・サーバー定義を作成して、Oracle BI Serverへの接続をサポートします。

1. ODIデザイナの「トポロジ」タブで、「物理アーキテクチャ」にある「Oracle BIテクノロジ。」を展開します。

2. 「Oracle BIテクノロジ。」で、BI Applicationsの新しいデータ・サーバーを作成します。

3. 新しいサーバーの「定義」タブで名前を入力し、「接続」の詳細でOracle BI EE Serverの管理ユーザーのユーザーとパスワードの資格証明を入力します。

4. 「JDBC」タブで、「JDBCドライバ」に「oracle.bi.jdbc.AnaJdbcDriver」と入力します。

5. 「JDBC URL」に「jdbc:oraclebi://<IPアドレスまたはOracle BI EE Serverのホスト名>:9703/」と入力します。

注意:

JDBC URLの先頭と末尾にはスペースを含めないようにしてください。

6. BI Applicationsのデータ・サーバーに新しい物理スキーマを作成します。「定義」タブで、「カタログ」(「カタログ」)のコア、および「カタログ」(「作業カタログ」)のコアを指定します。

7. ODIデザイナの「トポロジ」タブで、「論理アーキテクチャ」を展開し、作成した物理スキーマにOBI_BIAPPS11G論理スキーマを割り当てます。

Endeca Serverのターゲットの作成

Endeca Serverの統合をサポートするため、ODI物理アーキテクチャ内にEndeca Server用のターゲットODIデータ・サーバー定義を作成します。

1. ODIデザイナの「トポロジ」タブで、「物理アーキテクチャ」にある「Endeca Serverテクノロジ」を展開します。

2. 「Endeca Serverテクノロジ」で、BI Applicationsの新しいデータ・サーバーを作成します。

3. 新しいサーバーの「定義」タブで名前を入力します。「接続」の詳細で、「ユーザー」フィールドと「パスワード」フィールドを空のままにします。

4. 「JDBC」タブで、「JDBCドライバ」を空のままにします。

5. 「JDBC URL」に、「http://<IPアドレスまたはEndeca Serverのホスト名>:7001/endeca-server」と入力します。

注意:

JDBC URLの先頭と末尾にはスペースを含めないようにしてください。

6. BI Applicationsのデータ・サーバーに新しい物理スキーマを作成します。「定義」タブで、「カタログ」(「カタログ」)、および「カタログ」(「作業カタログ」)を空のままにしておくことができます。

7. ODIデザイナの「トポロジ」タブで、「論理アーキテクチャ」を展開し、作成した物理スキーマにOEID_BIAPPS11G論理スキーマを割り当てます。

Endecaファイル用のデータ・サーバーの作成

Endeca Serverの統合をサポートするため、Endeca Webサービスによってサンプル・アプリケーションを含むビューXMLをロードするために使用されるEndecaファイル用のターゲットODIデータ・サーバー定義をODI物理アーキテクチャ内に作成します。

1. ODIデザイナの「トポロジ」タブで、「物理アーキテクチャ」にある「ファイル・テクノロジ」を展開します。

2. 「ファイル・テクノロジ」で、BI Applicationsの新しいデータ・サーバーを作成します。

3. 新しいサーバーの「定義」タブで名前を入力します。「接続」の詳細で、「ユーザー」フィールドと「パスワード」フィールドを空のままにします。

4. 「JDBC」タブで、「JDBCドライバ」に「com.sunopsis.jdbc.driver.file.FileDriver」と入力します。

5. 「JDBC URL」に「jdbc:snps:dbfile?OPT=TRUE」と入力します。

注意:

JDBC URLの先頭と末尾にはスペースを含めないようにしてください。

6. BI Applicationsのデータ・サーバーに新しい物理スキーマを作成します。「ディレクトリ」(「スキーマ」)および「ディレクトリ」(「作業スキーマ」)に、ビューXMLファイルが含まれているディレクトリ(たとえばC:\Temp)を使用します。このディレクトリは、ODIエージェントがインストールされており、ビューXMLファイルにアクセス可能なサーバーからの相対位置である必要があります。

注意:

サンプル・アプリケーションのビューXMLは、BIAPPSのインストール先の<ミドルウェア・ホーム>\Oracle_BI1\biapps\admin\provisioning\endeca\OracleBIApps_Endeca.zipにあります。

7. ODIデザイナの「トポロジ」タブで、「論理アーキテクチャ」を展開し、作成した物理スキーマにDW_OEID_SRCFILES論理スキーマを割り当てます。

Endeca Webサービス・プロシージャを使用したビューのエクスポートとインポート

Endeca Webサービス・プロシージャではビューのエクスポートがサポートされています。サンプル・アプリケーションのビューXMLだけでなく、他のサブジェクト領域のビューもエクスポートおよびインポートできます。Endecaのビューでは、Endeca問合せ言語(EQL)を使用してEndeca Serverで追加のデータ操作を行うことも可能です。EQLはSQLに似たビューであり、通常はStudioで作成しますが、格納先はサーバーでありエクスポートとインポートが必要になります。8つのサブジェクト領域(サンプル・アプリケーション)には、ODIパッケージ内にEndecaのビューをロードするためのEndeca Webサービス・プロシージャが含まれています。

ビューをエクスポートするには:

1. ODIパッケージを新規作成し、Endeca Webサービス・プロシージャを追加します。パッケージにExport Viewsなどの名前を付けます。

2. 次のプロシージャ・オプションを設定します。

- ENDECA_WS_RELATIVE_PATH: /ws/sconfig/<データ・ドメイン名>

- REQUEST_FILE_NAME: Export_Views.xml

- RESPONSE_FILE_NAME: レスポンス・メッセージ・ファイルのビュー・エクスポートの名前。命名規則は、<データ・ドメイン名>_Views.xmlです。

3. BIAPPS_OEID_FILE物理スキーマ内に入力したディレクトリにExport_Views.xmlファイルを配置または保存します。これは、プロシージャがレスポンス・ファイル(RESPONSE_FILE_NAME)を出力するディレクトリでもあります。

4. ODIパッケージを実行します。成功すると、レスポンス・ファイルにビューがエクスポートされます。

ビューをインポートするには:

1. エクスポートされたビューXMLは、インポートまたは再インポートする前にフォーマット設定する必要があります。XMLをテキスト・エディタで開き、validatedSemanticEntityを検索し、それをvalidatedSemanticEntityに置換します。

2. listEntitiesResponseを検索し、それをputEntitiesに置換します。

3. 新規または既存のODIパッケージを使用して、Endecaデータ・ドメインをロードします。パッケージに、最後の手順としてEndeca Webサービス・プロシージャを追加します。

4. 次のプロシージャ・オプションを設定します。

- ENDECA_WS_RELATIVE_PATH: /ws/sconfig/<データ・ドメイン名>

- REQUEST_FILE_NAME: ビューのエクスポートによって作成されたレスポンス・メッセージ・ファイルの名前。命名規則は、<データ・ドメイン名>_Views.xmlです。

5. BIAPPS_OEID_FILE物理スキーマ内に入力したディレクトリにExport_Views.xmlファイルを配置または保存します。これは、プロシージャがレスポンス・ファイル(RESPONSE_FILE_NAME)を出力するディレクトリでもあります。

6. ODIパッケージを実行します。成功すると、ターゲット・データ・ドメインにビューがインポートされます。

データ・ウェアハウスに対する接続の確認

Oracle Business Analytics Warehouseのデータ・サーバーに正しい接続情報が設定されていることを確認します。

1. ODIデザイナの「トポロジ」タブで、データ・ウェアハウスに対応した「物理アーキテクチャ」にある「テクノロジ」を展開します。

2. BIAPPS_DWデータ・サーバーを選択します。

3. 「定義」タブで、OBAWデータベースに対する接続用のユーザー名とパスワードを入力します。

4. 「JDBC」タブで、データベースに対するJDBCドライバの正しい情報を入力します。

ODIエージェントの構成

ODIエージェントは、スタンドアロン・エージェントまたはJava EEエージェントのいずれかとして存在します。Endeca IKM jarファイル(ODIエージェントとともに含める必要があります)は、BI Applicationsのインストール先の<ミドルウェア・ホーム>\Oracle_BI1\biapps\admin\provisioning\endeca\OracleBIApps_Endeca.zip (Import/Libディレクトリ)にあります。

ODIエージェントがスタンドアロン・エージェントである場合は、JARファイルをODIドライバのディレクトリにコピーします。ODIドライバのディレクトリは、<インストール・パス>\Oracle\Middleware\Oracle_ODI1\oracledi\agent\drivers (またはUNIXにおけるこれと同等のパス)です。その後、ODIエージェントを再起動します。

ODIエージェントがWebLogic Server上で実行されるJavaアプリケーションである場合は、次の手順を実行します。

1. <ORACLE_HOME>biapps/odi/bia_odiagent/の下にjlibディレクトリを作成します。

2. ODIエージェントのクラスパス内にある必要なすべてのEndeca IKM jarsを<ORACLE_HOME>biapps/odi/bia_odiagent/jlibにコピーします。

3. ODIサーバーを再起動します。

IKMおよびjarファイルの詳細は、『Endeca SQLからEndeca Serverインストールおよび使用ガイド』を参照してください。

ターゲット・スキーマODIのロードのインタフェースでスキーマの適用を無効にする

スキーマの作成後、最初のEndeca ETLの実行時に、ODIフレックスフィールドを編集するのではなくEndeca Studioを使用して、Endeca Serverのスキーマ・メタデータを修正できます。カスタマイズしたスキーマが上書きされるのを防止するには、ターゲット・スキーマのロードのインタフェースのAPPLY_SCHEMAオプションをFALSEに設定します。

1. ODIデザイナの「プロジェクト」の下で、サブジェクト領域のパッケージを開き、「ダイアグラム」タブを選択します。

2. TLP_OEID_<サブジェクト領域の名前>Load_Tgt_Schemaステップを右クリックし、「リンクされたオブジェクトの編集」を選択します。新しいタブにターゲット・スキーマのロードのインタフェースが開かれます。

3. 「フロー」タブで、「ターゲット」(BIAPPS_OEID)をクリックします。プロパティ・インスペクタのオプション領域にあるAPPLY_SCHEMAオプションをfalseに変更します。

4. インタフェースを保存して閉じ、次にパッケージを保存して閉じます。

5. シナリオを生成します。「プロジェクト」で「パッケージ」を右クリックし、「シナリオの生成」を選択し、「OK」をクリックしてデフォルトを受け入れます。

6. 新しいシナリオのバージョンを覚えておきます。

覚えておいたバージョン番号を使用し、「コンテキスト」、「論理エージェント」および「ログ・レベル」を選択することによって、シナリオを直接実行できます。また、Endecaロード計画からシナリオを実行することもできます。シナリオの各手順で、ロード計画によってバージョンが-1に設定されます。これによって、最も新しく生成されたシナリオが使用されます。シナリオはODIデザイナ内で直接実行されます。

5.3.4 設定手順: データのロード

ODIのシナリオを直接実行するか、またはEndecaロード計画を実行することによって、データをEndecaドメインにロードできます。BI Applicationsのインストールとともに提供されるソースおよびターゲットのデータ・ストアには、Oracle BI Applicationsリポジトリ(RPD)のすべての論理列が含まれます。ビジネス要件に応じてこれらをカスタマイズし、マッピングを追加または削除できます。

変数の設定および宣言

シナリオを直接実行する場合、実行時にセッション変数を設定できます。次のODI変数は実行時にオーバーライドできます。

- ENDECA_DATADOMAIN_PROFILE: この変数はデータ・ドメイン・プロファイルの名前です(データ・ドメイン・プロファイルが作成された場合)。パフォーマンスを最大にするためのデータ・ドメイン・プロファイルの作成の詳細は、「Endecaデータ・ドメイン・プロファイルの作成によるCPUコア数の最適化」を参照してください。

- ENDECA_OBIEE_SQL_PREFIX: この変数はデフォルトの優先通貨(GLOBAL1)をオーバーライドするのに使用されます。

- ETL_PREDICATE_EXTRACT: この変数はフィルタを入力するのに使用されます。

次のODI変数を使用するには、ODIパッケージに対する変更が必要になります。

- ENDECA_DATADOMAIN

- ENDECA_DATALOAD_LOG_FILE_PATH

ENDECA_DATADOMAINまたはENDECA_DATALOAD_LOG_FILE_PATH(またはその両方)の値を変更するには:

1. デザイナの「プロジェクト」の下で、サブジェクト領域のパッケージを開き、「ダイアグラム」タブを選択します。

2. ENDECA_DATADOMAIN変数またはENDECA_DATALOAD_LOG_FILE_PATH変数を選択します。「プロパティ」ペインの「一般」タブで目的の値を入力します。

3. パッケージを保存して閉じます。

4. インタフェースを保存して閉じ、次にパッケージを保存して閉じます。

5. シナリオを生成します。「プロジェクト」で「パッケージ」を右クリックし、「シナリオの生成」を選択し、「OK」をクリックしてデフォルトを受け入れます。起動パラメータを尋ねられたら「すべてを使用」を選択し、「OK」をクリックします。

シナリオの直接実行

ODIシナリオを直接実行するには:

1. ODIデザイナで実行するシナリオを開きます。

2. 「実行」をクリックします。

3. 「コンテキスト」、「論理エージェント」および「ログ・レベル」を選択します。

4. デフォルトを使用するか、または必要に応じてセッション変数を変更します。たとえば、BIAPPS.ETL_PREDICATE_EXTRACTはカスタマイズ可能なフィルタ変数です。

5. 「OK」をクリックします。

Endecaロード計画の実行

Endecaパッケージを実行するための事前定義されたロード計画が用意されています。このロード計画には、それぞれのOEID_シナリオでIS_ENDECA_DEPLOYED変数が'Y'または'N'のいずれに設定されているかを評価する手順が含まれています。これはEndeca Fact Groupsと関係があります。データ・リフレッシュのためにロード計画を実行する頻度は、使用状況に応じて異なります。通常のロードのコストによっては夜間実行が適切である場合があります。また、リアルタイムのデータが不要な場合はより低い頻度で実行しても構いません。履歴分析のみを実行する場合は、必要なのは最初のロードだけです。

注意:

Configuration Managerには、ODIリポジトリを設定してEndecaをロードする機能が含まれていません。ロード計画は、ODI Webコンソールまたはクライアントを使用して直接実行されます。

IS_ENDECA_DEPLOYED変数の設定とODIロード計画の実行

実行するシナリオを選択するには、IS_ENDECA_DEPLOYED変数を設定し、ロード計画を実行します。

1. ODIクライアントで、「ロード計画およびシナリオ」→「事前定義されたロード計画/Endeca」の下にある「BIアプリケーションDWからEndecaロード計画へ」を開きます。

2. 「ステップ」タブを選択し、「パラレル・ステップ」を展開します。

3. "OEID_"の接頭辞の付いた、実行するシナリオが含まれるサブステップを選択します。たとえば、OEID_COSTING_INVENTORY_VALUATION_FGは原価計算在庫評価ファクト・グループを表します。

4. プロパティ・インスペクタの「変数」セクションの下で、BIAPPS.IS_ENDECA_DEPLOYEDの値をYに設定します。値を入力した後に、Yは大文字であること、および「リフレッシュ」チェック・ボックスが選択されていないことを確認してください。

5. 実行対象のシナリオが含まれているそれぞれのOEID_サブステップに対して前述の手順を繰り返します。

6. ロード計画を保存します。

7. ロードを実行して監視し、Yが設定されたサブステップを実行します。

フィルタと通貨の設定

事前定義されたEndecaロード計画の中にあるENDECA_OBIEE_SQL_PREFIXやETL_PREDICATE_EXTRACTなどの変数は、オーバーライドしてロード計画に保存できます。フィルタおよび通貨はロード計画内で直接変更できます。これを行うには、「シナリオ変数」の下でシナリオ・ステップを選択し、チェックして新しい値を設定します。

5.3.5 設定手順: Endecaアプリケーションの新規作成

アプリケーションの新規作成

Endecaアプリケーションを新規作成するには:

1. Endeca Studioに管理者としてログインします。

2. ギアのアイコンをクリックし、コントロール・パネルで「Endeca Server」を選択します。

3. 「新規接続」をクリックし、必要なパラメータを入力します。

4. 接続を確認し、オプションでテストを行います。

5. 「ホームへ戻る」をクリックし、ホーム・ページに戻ります。

6. 「新規アプリケーション」をクリックします。

7. アプリケーション名およびアプリケーションの説明を入力します。

8. 「データ・ソースの選択」の下で、事前作成されている「Endeca Server」を選択します。

9. 管理対象データ接続を選択します。

10. 「完了」をクリックします。デフォルト・テンプレートが作成されます。

5.4 ODIパッケージ、インタフェースおよびプロシージャの設計の概要

この項では、EndecaのODIパッケージ、インタフェースおよびプロシージャの独自の設計の詳細について説明します。BI Applicationsのインストールとともに提供されるソースおよびターゲットのデータ・ストアには、Oracle BI Applicationsリポジトリ(RPD)のすべての論理列が含まれます。ビジネス要件に応じてこれらをカスタマイズし、マッピングを追加または削除できます。

新しいフレックスフィールド

ODIデータ・ストアの列内のフレックスフィールド・プロパティは、Endeca Serverの列の設定を構成します。たとえば、Endecaのプロパティによって、列の値がテキストで検索可能か、値で検索可能かなどを定義できます。これらのプロパティはすべて"Endeca Property"という接頭辞で始まっています。

パッケージ

それぞれのサブジェクト領域(SA)には、次のパッケージ設計パターンがあります。

- ENDECA_DATADOMAIN変数: SAデータ・ドメインの名前。例: OEID_Project_Cost。

- ENDECA_DATADOMAIN_PROFILE変数: データ・ドメイン・プロファイル。空にすると、デフォルトのデータ・ドメイン・プロファイルが使用されます。

- ENDECA_DATALOAD_LOG_FILE_PATH変数: ログ・ファイルのパス/名前。例: OEID_Project_Cost_ENDECA_DATALOAD.LOG。

- ENDECA_OBIEE_SQL_PREFIX変数: オプションのOracle BI EE接頭辞。通常は通貨用に設定されます。たとえば、変数をPREFERRED_CURRENCY='Global Currency 4'のように設定します。

- ETL_PREDICATE_EXTRACT変数: オプションのOracle BI EEのwhere句(フィルタ)条件。デフォルトは1=1です。

- TLP_OEID_<SA>_Load_Tgt_Schemaインタフェース。例: TLP_OEID_Project_Cost_Load_Tgt_Schema

- インタフェースはデータをロードしません(フィルタが1=2に設定されています)。

- データ・ドメインがまだ存在していない場合、インタフェースはデータ・ドメインを作成します。

- マッピングにはサブジェクト領域のすべての列が含まれており、スキーマのみがロードされます。

注意:

データをロードするインタフェースによっていずれかの列が変更される場合、このロード・ターゲット・スキーマ・インタフェースの列を更新し、それを維持する必要があります。

- Studioで行われた属性設定を保持するための"APPLY SCHEMA"オプションを無効にするIKMオプションがあります。

- TLP_OEID_<SA>_<ファクト表名>インタフェース。例: TLP_OEID_Project_Cost_Fact_Project_Cost。

- インタフェース(サブジェクト領域によっては複数ある場合もあります)によって、Oracle BI EEからデータが抽出され、Endecaがロードされます。

- データセットの収集名(例: "Fact_Project_Cost")ごとに1つのインタフェースが存在します。

- 各インタフェースは、1つの非正規化ファクトのスター・スキーマをロードします。

- 各インタフェースは、毎回のロードの前に収集データを切り捨てます。つまり、毎回のロードは増分ではなく破棄されます。

各インタフェースは次の項目を使用します。

- LKM: LKM BIAPPS OBIEEからSQL BMMFETCH

- IKM: IKM SQLからEndeca Server

データ・ストア

- ソース: Oracle BI Applications\Oracle BI Applications Business Model\Core

- ターゲット: Oracle BI Applications\Oracle BI Applications Endeca\Core

Endeca Webサービス・プロシージャ

- このプロシージャは、SQLからEndeca Server IKMで使用されるのと同じjarを必要とします。

- サンプル・アプリケーションのサブジェクト領域だけは、最後の手順としてビューをロードするためのEndeca Webサービス・プロシージャがパッケージ内に追加されています。

- Endeca Webサービス・プロシージャは、オプションで任意のサブジェクト領域に含めることができます。また、独自のODIパッケージ内でスタンドアロンで実行することもできます。

5.5 サンプル・アプリケーションのデプロイ

この項では、Endecaサンプル・アプリケーションをデプロイする方法について説明します。Endecaサンプル・アプリケーションはOracle Software Delivery CloudのBI Applications 11.1.1.8.1 Media Packからダウンロードでき、独自のアプリケーションを作成するためのベースとして使用できます。8個のサンプル・アプリケーションが用意されており、Media PackのBI Applications 11.1.1.8.1のEndecaサンプル・アプリケーション用のサポート・ファイルの下にデータ・ドメインおよびStudioアプリケーション(.larファイル)が含まれています。また、BI ApplicationsのインストーラによってビューXMLファイルがデプロイされます。一部のサンプル・アプリケーションにはエンリッチ・テキストに基づくタグ・クラウドが含まれており、データ・ドメインを再ロードする場合はルールを再実行する必要があります。データ・ドメインがリセットされた場合は、ルールを再作成する必要があります。

サンプル・データ・ドメインのインポート

インストールに含まれているデータ・ドメイン・ファイルは、$DOMAIN_HOME\EndecaServer\offlineに配置されます。

endeca-cmdユーティリティで次のコマンドを使用してデータ・ドメインをインポートし、有効にできます。

CALL endeca-cmd import-dd my_dd1 --offline-name my_dd_offline1
CALL endeca-cmd enable-dd my_dd1

スクリプトを使用することによって、複数のデータ・ドメインをインポートして有効にできます。DOSの.batスクリプトの例を次に示します。

CALL endeca-cmd import-dd OEID_Sales_Order_Lines \--offline-name OEID_Sales_Order_Lines
CALL endeca-cmd enable-dd OEID_Sales_Order_Lines
CALL endeca-cmd import-dd OEID_Project_Performance \--offline-name OEID_Project_Performance
CALL endeca-cmd enable-dd OEID_Project_Performance
CALL endeca-cmd import-dd OEID_SIA_Admissions_and_Recruiting_Student_Response \--offline-name OEID_SIA_Admissions_and_Recruiting_Student_Response
CALL endeca-cmd enable-dd OEID_SIA_Admissions_and_Recruiting_Student_Response
CALL endeca-cmd import-dd OEID_SIA_Admissions_and_Recruiting_Application_Evaluation \--offline-name OEID_SIA_Admissions_and_Recruiting_Application_Evaluation
CALL endeca-cmd enable-dd OEID_SIA_Admissions_and_Recruiting_Application_Evaluation
CALL endeca-cmd import-dd OEID_Employee_Expenses_Overview \--offline-name OEID_Employee_Expenses_Overview
CALL endeca-cmd enable-dd OEID_Employee_Expenses_Overview
CALL endeca-cmd import-dd OEID_Manufacturing_Work_Order_Performance \--offline-name OEID_Manufacturing_Work_Order_Performance
CALL endeca-cmd enable-dd OEID_Manufacturing_Work_Order_Performance
CALL endeca-cmd import-dd OEID_Human_Resources_Recruitment \--offline-name OEID_Human_Resources_Recruitment
CALL endeca-cmd enable-dd OEID_Human_Resources_Recruitment
CALL endeca-cmd import-dd OEID_Manufacturing_Actual_Production \--offline-name OEID_Manufacturing_Actual_Production
CALL endeca-cmd enable-dd OEID_Manufacturing_Actual_Production

endeca-cmdユーティリティの使用の詳細は、『Oracle Endeca Server管理者ガイド』の「Endeca Serverコマンド・リファレンス」の章を参照してください。データ・ドメインのインポート、エクスポート、有効化または無効化の詳細は、『Oracle Endeca Server管理者ガイド』の「データ・ドメインの管理」の章を参照してください。

Endeca Studio Applicationのサンプル・アプリケーションのインポート

Endeca Studioのサンプル・アプリケーションをインポートするには、インポートの前に新規アプリケーションを作成しておく必要があります。デフォルト・テンプレートを使用してアプリケーションを新規作成する手順は次のとおりです。

1. Endeca Studioに管理者としてログインします。

2. 右上にあるギアのアイコンをクリックしてコントロール・パネルに移動し、「Endeca Server」に移動します。

3. 「新規接続」ボタンをクリックし、必要なパラメータを入力します。典型的なパラメータの例を次に示します。

Connection ID: OEID_Employee_Expenses_Overview

{
"dataDomainName": "OEID_Employee_Expenses_Overview",
"name": "OEID_Employee_Expenses_Overview",
"port": "7001",
"server": "hostname"
}

注意:

サンプル・アプリケーション用のカスタムOBIA Studioセキュリティ・マネージャを適用する場合、提供されているセキュリティ列構成ファイル内に指定されている接続IDと同期するためには、接続IDとデータ・ドメイン名が一致している必要があります。セキュリティ列構成ファイルの詳細は、第5.6項「カスタムBIアプリケーションのセキュリティ・マネージャの適用」を参照してください。

4. 接続を検証し、「保存」をクリックします。オプションで、「接続のテスト」ボタンを使用して接続を確認します。

5. 「ホームへ戻る」をクリックし、ホーム・ページに戻ります。

6. 「新規アプリケーション」ボタンをクリックします。

7. アプリケーション名(例: Employee Expenses)およびアプリケーションの説明を入力します。

8. 「データ・ソースの選択」の下で、「事前ビルド済Endeca Serverの使用」を選択します。

9. 管理対象データ接続を選択します。例: OEID_Employee_Expenses_Overview。

10. 「完了」をクリックし、デフォルト・テンプレートを作成します。

サンプル・アプリケーション(.larファイル)のインポート

Media Pack内に提供されているサンプル・アプリケーションをインポートするには:

1. 右上にあるギアのアイコンをクリックしてコントロール・パネルに移動し、「アプリケーション」を選択します。

2. 一連のアプリケーションの中に.larファイルをインポートするには、「アクション」→「ページの管理」を選択します。

3. 「すべてのページ」の下の「エクスポート/インポート」タブで、「インポート」タブを選択します。

4. 「参照」または「ファイルの選択」をクリックし、目的の.larファイルを選択します。

5. 「インポート対象」セクションの内容はデフォルトのままにします。.larファイル内に存在しないページを宛先の環境から削除するには、「欠落ページの削除」チェック・ボックスを選択します。インポート内にすべてのコンポーネント構成が含まれるようにするには、「ユーザー・プリファレンス」チェック・ボックスを選択します。

6. 「インポート」をクリックします。

テキスト・エンリッチメント(語の抽出)/エンリッチメント・ルール

サンプル・アプリケーションの中には、エンリッチ・テキストに基づくタグ・クラウドが含まれているものがあります。テキスト・エンリッチメント・パイプラインはStudio内ではなくデータ・ドメイン内に格納されるため、タグ・クラウドはサンプル・データ・ドメインをインポートした後に動作させる必要があります。インポートせずにサンプル・アプリケーションのデータ・ドメインをロードした場合、エンリッチ属性が存在しないためエンリッチ・タグ・クラウドにエラー・メッセージが表示されます。テキスト・エンリッチメント・パイプラインを再作成する必要があります。その手順は次のとおりです。

1. 「アプリケーション設定」→「データ・セット」→「エンリッチメント」を選択し、「エンリッチメントの追加」をクリックして語を抽出し、エンリッチ対象の自由形式テキスト(非構造化コンテンツ)が含まれる属性(1つまたは複数)を選択します。

2. 出力の名前を指定します。たとえば、属性名(語)を指定します。残りの設定はデフォルトのままで構いません。

3. 「実行」ボタンをクリックし、エンリッチメントを処理します。

4. タグ・クラウドの設定を編集し、無効な出力属性を新しいものに置き換えます。

データが置換されるとき、またはEndecaデータ・ドメインにデータが再ロードされるときは、タグ・クラウドおよびエンリッチメント・パイプラインは引き続き動作しているため再作成する必要はありません。ただし、エンリッチメント・パイプラインは、前述の説明にあるように「実行」ボタンをクリックして再実行する必要があります。これにより、エンリッチ・データが再作成されます。この再作成を行わないと、エンリッチ・タグ・クラウドにデータが表示されません。エンリッチメントを再実行する手順は次のとおりです。

1. 「アプリケーション設定」→「データ・セット」の順に移動し、エンリッチメント・パイプラインを持つデータセットを選択します。

2. 「エンリッチメント」タブを選択し、「実行」ボタンをクリックしてエンリッチメントを実行します。

3. 「実行」ボタンをクリックし、エンリッチメントを処理します。

絞込みルール

複数のデータ・セットが含まれるアプリケーションでは、絞込みルールによって異なるデータ・セットからの属性を接続できます。たとえば、自動車データの販売データ・セットには、販売された自動車の型と車両識別番号(VIN)が含まれます。また、保証請求が格納される別のデータ・セットにも、保証請求の申し立てが行われる自動車の型とVINが含まれます。この場合、型とVINの属性の絞込みルールを作成することによって、ユーザーが一方のデータ・セットを型またはVINで絞り込むと、他方のデータ・セットもその型またはVINで絞り込まれます。

絞込みルールの使用の詳細は、『Oracle Endeca Information Discovery Studioユーザー・ガイド』の「絞込みルールを使用して異なるデータ・セットからの属性をリンクする」の章を参照してください。

5.6 カスタムBIアプリケーションのセキュリティ・マネージャの適用

この章では、Oracle BI ApplicationsおよびOracle WebLogicとの相互運用性のためにEndecaのセキュリティを設定する方法について説明します。ここには、必要なBIロールの割当て、Endeca資格証明ストアの作成、Oracle BI Applicationsのセキュリティ・マネージャで必要となるファイルの包含、Endeca Studioの新しいユーザーの定義、およびEndeca Serverのパフォーマンスまたはユーザー・エクスペリエンスを向上させるためのその他のオプションのセキュリティ構成に関する情報が記載されています。

OBIEEユーザーへのBIImpersonatorロールの割当て

Oracle BI Applicationsのセキュリティ・マネージャでは、管理者およびインパーソネータのロールを持つOracle BI Enterprise Editionユーザーが必要です。このユーザーは、Endecaアプリケーション内のセキュリティ・フィルタを適用するために必要な情報を取得するのに使用されます。既存のOracle BI EE管理者アカウントにインパーソネータ・ロールを追加する手順は次のとおりです。

1. Oracle Business IntelligenceのEnterprise Managerに管理者権限でログインします。

2. 右のペインで「Business Intelligence」を展開します。

3. coreapplicationを右クリックし、「セキュリティ」→「アプリケーション・ロール」を選択し、「アプリケーション・ロール」ページに移動します。

4. デフォルトでは、obiアプリケーション・ストライプが選択され、デフォルトのアプリケーション・ロールが表示されます。"BI"という接頭辞を持つロール名を探します。

5. 「メンバー」のリストで、「BIImpersonator」ロールをクリックし、「編集」をクリックします。

6. 「追加」をクリックし、「プリンシパルの追加」ダイアログ・ボックスでユーザーのタイプを検索し、管理ユーザーを見つけます。

Endeca Studio内での資格証明ストアの作成および設定

管理者およびインパーソネータのロールを持つOracle BI Enterprise Editionのアカウントの資格証明は、Endeca Studioドメインの資格証明ストア内にローカルで保存されます。BI Applicationsのセキュリティ・マネージャはこの資格証明ストアからパスワード情報を取得し、JDBCを使用してOracle BI Enterprise Editionに接続します。資格証明ストアを設定するには次の手順を実行します。ここでは、WebLogicがすでにインストールされており、Endeca Studioドメインの作成前にこの手順が実行されることを想定しています。既存のドメインを拡張してEnterprise Managerを含めることも可能です。

1. Endeca Serverのインストールの一部としてOracle Application Development Frameworkがインストールされていることを確認します。同じWebLogic Server上にEndeca Studioがインストールされている場合は、ADFがすでに利用可能になっている可能性があります。

2. 最初にEndeca Studioドメインを作成するときに、Oracle Enterprise Managerを選択します。JRFは自動的に含まれます。Studioのドメインがすでに作成されている場合は、既存のドメインを拡張してEnterprise Managerを含めることができます。

3. WebLogicを起動し、Enterprise Managerを使用してOBIEE資格証明情報を保存するための資格証明ストアを作成します。

1. Enterprise Managerにログインし、WebLogicドメインでendeca_studio_domainを右クリックし、「セキュリティ」→「資格証明」を選択します。新しいマップ(例: oracle.bi.enterprise)およびキー(例: repository.OBIA)を作成し、OBIEEのユーザー名とパスワードの情報を保存します。

注意:

マップおよびキーに割り当てられるパスワードは、管理者およびインパーソネータのロールが割り当てられるOBIEEアカウントに対応している必要があります。

Oracle BI Applicationsのセキュリティ・マネージャ関連のファイルを含める

管理者およびインパーソネータのロールを持つOracle BI Enterprise Editionのアカウントの資格証明は、Endeca Studioドメインの資格証明ストア内にローカルで保存されます。BI Applicationsのセキュリティ・マネージャはこの資格証明ストアからパスワード情報を取得し、JDBCを使用してOracle BI Enterprise Editionに接続します。資格証明ストアを設定するには次の手順を実行します。ここでは、WebLogicがすでにインストールされており、Endeca Studioドメインの作成前にこの手順が実行されることを想定しています。既存のドメインを拡張してEnterprise Managerを含めることも可能です。

Endeca Studio 3.1のWebLogicバージョンでは、.earインストール・ファイルにカスタムBIアプリケーションのセキュリティ・マネージャの.jarファイルを追加する必要があります。ユーティリティを使用して.earファイルを解凍し、\APP-INF\lib\ディレクトリに.jarファイルをコピーします。ファイルをコピーする手順は次のとおりです。

1. Endeca Studioのインストール.earファイルのコピーを別のファイル名で保存します(例: OBIA-endeca-portal-weblogic-3.1.13849.ear)。

2. 圧縮ユーティリティを使用して、Endeca Studioの.earファイルの\APP-INF\lib\の下に、OBIAMDEXSecurityManager.jarおよびbijdbc.jarを追加します。

3. インストール方法に従ってWebLogicに.earをデプロイします。.earのデプロイの詳細は、『Oracle Endeca Information Discovery Studioインストール・ガイド』のWebLogicドメインへのStudioのデプロイに関する項を参照してください。既存のEndeca Studioのデプロイメントがある場合は、必ず最初にアンデプロイしてください。デプロイメントで使用した名前を覚えておいてください。system-jazn-data.xmlを変更するときにこの値を使用します。このデプロイメントの通常の名前はOBIA-endeca-portal-weblogic-3です。

4. WebLogicサーバーの$MW_HOME\user_projects\domains\endeca_studio_domainの下にXMLおよびUser_Inputという名前のディレクトリを追加します。

5. config.propertiesファイルをUser_Inputディレクトリに追加または作成します。次のようにパラメータを設定します。次の場所にサンプル・ファイルが用意されています。<Middleware Home>\Oracle_BI1\biapps\admin\provisioning\endeca\OracleBIApps_Endeca.zip (OBIAMDEXSecurityManager/User_Input/)。

OBIEE_HOST=<OBIEE hostname>
OBIEE_USERID=<OBIEE username with Admin and Impersonator Roles assigned>
OBIEE_JDBC_PORT=<port number, usually 9703>
OBIEE_USERID_MAP=<Credential Store Map Name>
OBIEE_USERID_KEY=<Credential Store Key Name>

6. securitycolumns.csvファイルをUser_Inputディレクトリに追加または作成します。次の場所にサンプル・ファイルが用意されています。<Middleware Home>\Oracle_BI1\biapps\admin\provisioning\endeca\OracleBIApps_Endeca.zip (OBIAMDEXSecurityManager/User_Input/)。この.csvファイルには、Endeca Server Connection ID、Collection NameおよびSecurity Columnsという3つの列があり、セキュリティ列を関連付けるのに使用されます。

7. Endeca Studioを起動し、ログインします。コントロール・パネルで「フレームワーク設定」を選択し、df.mdexSecurityManagerを"com.endeca.portal.data.security.DefaultMDEXSecurityManager"から"com.endeca.portal.extensions.OBIAMDEXSecurityManager"に変更します。

8. 「設定の更新」をクリックします。

9. WebLogicサーバーを停止します。

10. $DOMAIN_HOME\config\fmwconfigにあるsystem-jazn-data.xmlファイルの<system-policy>タグおよび<jazn-policy>タグの下に、次のエントリを追加します。このエントリには、資格証明ストアにアクセスするためのStudioの権限が含まれています。 例:

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<appName>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=<mapName>,keyName=<keyName></name>
<actions>*</actions>
</permission>
</permissions>
</grant>

値の例には、次のものが含まれます。

- appName=OBIA-endeca-portal-weblogic-3

- mapName=oracle.bi.enterprise

- keyName=repository.OBIA

11. WebLogic Endeca Studio Serverを再起動し、新しいカスタム・セキュリティ・マネージャが適用されてEndeca Studioで使用されるようにします。

オプション: WebLogic Serverのヒープ領域を拡大してEndeca Studioのパフォーマンスを向上させる

setDomainEnvスクリプト・ファイルを更新します。このファイルの名前は、Windows環境ではsetDomainEnv.cmd、Linux環境ではsetDomainEnv.shです。このファイルは、ドメイン・ディレクトリのbinサブディレクトリ(<MiddlewareHomeDirectory>/user_projects/domains/endeca_studio_domain/bin/)にあります。

setDomainEnv.cmdファイル内で次の部分を検索します。

if NOT "%USER_MEM_ARGS%"=="" (

s et MEM_ARGS=%USER_MEM_ARGS%

)

前述の"if"ステートメントの前に次のステートメントを追加します。これにより、-Xmxの値が大きくなるか、またはメモリー・ヒープ・サイズが最大化されます。

set MEM_ARGS=-Xms128m -Xmx1280m %MEM_DEV_ARGS% %MEM_MAX_PERM_SIZE%

オプション: 冗長なデバッガ・ロギングを有効にする

ログ・ファイル(場所は$MW_HOME\user_projects\domains\endeca_studio_domain\eid-studio.log)へのデバッグ・メッセージのロギングを有効にするには、コントロール・パネルで「サーバー管理」を選択し、「ログ・レベル」タブを選択します。「カテゴリの追加」を選択して、次の内容を入力します。

- com.endeca.portal.extensions.OBIAMDEXSecurityManager (DEBUG)

- com.endeca.portal.extensions.OBIAMDEXSecurityManager.BIHandlers (DEBUG)

変更を有効にするため、一度ログアウトしてからログインします。Endeca Studioサーバーを再起動する場合、この手順を繰り返す必要があります。

Endeca Studioでのスクリーン名バリデータのオーバーライド

デフォルトでは、Endeca Studioにおいてはアンダースコアを含むスクリーン名は許可されません。スクリーン名バリデータをDefaultScreenNameValidatorからLiberalScreenNameValidatorに変更する必要があります。

1. Endeca Studioを停止します。

2. <%WLS_HOME>\user_projects\domains\endeca_studio_domain\eid\studioの下にあるportal-ext.propertiesファイルを開きます。既存のportal-ext.propertiesファイルをバックアップします。

3. このファイルの最後に次の内容を追加し、保存します。users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator

4. Endeca Studioを起動します。

Endeca Studioの新規ユーザーの定義(ロール・セキュリティ情報を取得するためのOBIEEユーザーIDに一致している必要がある)、およびStudioアプリケーションへのユーザーの追加

カスタムのOracle BI Applicationsセキュリティ・マネージャは、Oracle Business Intelligence Enterprise Editionに設定されているユーザーのアプリケーション・ロール情報、およびsecuritycolumns.csvに定義されているセキュリティ列に基づいて、Endecaにフィルタを適用します。

Oracle BI EEユーザーのために、Endeca Studio内にスクリーン名がBI EEのユーザーIDと一致している新しいユーザー・アカウントを作成する必要があります。Endeca Studioで新しいユーザーを作成する方法の詳細は、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』の「Studioでのユーザーの作成および編集」の章を参照してください。

デフォルトでは、Endecaユーザーは電子メール・アドレスを使用してログインしますが、ログイン方法がOracle BI Enterprise Editionと同じになるように、オプションでこのデフォルトの動作を変更できます。このデフォルトの動作の変更の詳細は、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』のStudioのユーザー名のタイプの構成に関する項を参照してください。Endeca Studioにおけるユーザー、ロールおよびアプリケーション権限の詳細は、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』の「アプリケーションの構成および削除」の章を参照してください。

Endeca Studioでのユーザーの追加およびStudioアプリケーションの権限の管理

ユーザーがStudioアプリケーションを参照できるようにするには、ユーザーをStudioアプリケーションに追加する必要があります。Endeca StudioでStudioアプリケーションにユーザーを追加する方法の詳細は、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』のアプリケーション・メンバーの追加および削除に関する項を参照してください。

デフォルトでは、ユーザーは新しいアプリケーションを作成できます。ユーザーがこれをできなくなるようにするには、パワー・ユーザー・ロールを削除します。このロールの削除の詳細は、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』のユーザーによるアプリケーション作成の禁止に関する項を参照してください。

アプリケーション・タイプは、「検出アプリケーション」ページでユーザーに対してアプリケーションを表示するかどうかを指定します。パブリックまたはプライベートのいずれかを設定できます。この値を変更するには、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』のアプリケーション・タイプの構成に関する項を参照してください。アプリケーション内のページの表示も制御できます。ページの表示を管理するには、『Oracle Endeca Information Discovery Studio管理およびカスタマイズ・ガイド』のページの表示タイプの構成に関する項を参照してください。

5.7 トラブルシューティング

この項では、トラブルシューティングに関する注意とガイドラインを提供します。

ETLのトラブルシューティング

ETLをトラブルシューティングするには、「ODIオペレータ」タブのログ情報を参照します。注目すべき主な領域として、行数、ビジネス・モデル・マッピングの論理SQLおよびETL内のステップのタイミングがあります。論理SQLをトラブルシューティングするには、オペレータからSQLを取得し、それをIssueSQL内でログ・レベル2で実行し、Oracle BI Serverのログ(nqquery.log)からSQL問合せを取得します。

リポジトリ・メタデータの変更はETLに影響を与える可能性があることに注意してください。RPDで結合の列が変更されると、ODIによるデータ抽出に影響を与える可能性があります。また、ROW_WID = 0の行が存在しないディメンション表にファクト表を結合した場合、ROW_WID = 0の行によって返されるデータの数が少なくなるか、またはデータが返されなくなります。

6 データ系統の調査

この章では、データ系統ダッシュボードを設定および使用する方法について説明します。

この章の内容は次のとおりです。

- 第6.1項「はじめに」

- 第6.2項「データ系統の設定」

- 第6.3項「データ系統ダッシュボードを設定するためのタスク」

- 第6.4項「データ系統ダッシュボードをロードおよびリフレッシュするためのタスク」

- 第6.5項「データ系統ダッシュボードを使用した分析の実行」

6.1 はじめに

データ系統ダッシュボードは、初期状態のBusiness Intelligence Applicationモジュールのメトリックおよびデータに関するレポート機能を提供します。これにより、Business Intelligenceのリポジトリおよび基礎となるETLマッピングを通じて、トランザクション・ソース・アプリケーションからのデータ分析が可能になります。データ系統ダッシュボードを使用することによって、ビジネス・アナリストや、ETLおよびリポジトリ・オブジェクトをカスタマイズするユーザーは、アプリケーションのレポートおよびダッシュボードのデータのソースの場所、Oracle BI Applicationsリポジトリ内でそれがモデル化される方法、ETL時にそれがロードされる方法を把握できます。

データ系統ダッシュボードは、Oracle Business Analytics Warehouseのカスタマイズの計画や実装を行う際に、ビジネス分析を実行したり、ソースからターゲットへのETLマッピングおよびデータ変換ロジックを理解したりするのに役立ちます。

6.2 データ系統の設定

概要

データ系統を設定するときに、OBAW内に事前作成されているデータ系統ウェアハウスの表の内容がETLパッケージによって移入されます。ETLパッケージは、次の5つのソースから系統メタデータをロードします。

- Oracle BI Applications Configuration Manager

- Oracle Data Integrator (ODI)作業リポジトリ

- Oracle BIプレゼンテーション・カタログ

- Oracle BIメタデータ・リポジトリ・ファイル(RPD)

- Oracle Fusion OLTPの表

1回限りの予備設定手順には、事前作成されているデータ系統ウェアハウスの表にデータ系統情報をロードするためのソースからのメタデータの準備、およびソースへのアクセスが含まれています。その後、メタデータおよびデータのリフレッシュを継続的に実行できます。

データ系統を設定するための手順のリスト

データ系統ダッシュボードをインストールして設定するには、次のタスクを順に実行する必要があります。それぞれのハイレベル・タスクを詳細な手順に分割した説明が記載されています。

1. データ系統をサポートするための環境を構成します。第6.3.1項「設定手順: ODIトポロジおよびロード計画の構成」の説明を参照してください。

2. プレゼンテーション・カタログ、ダッシュボードおよびRPDメタデータ・ファイルを生成するための抽出スクリプトを構成します。第6.3.2項「設定手順: RPDおよびプレゼンテーション・カタログの抽出スクリプトの構成」の説明を参照してください。

3. データ系統ウェアハウスの表を作成します。第6.3.3項「設定手順: データ系統ウェアハウスの表の作成」の説明を参照してください。

4. スクリプトを使用してメタデータを抽出します。第6.4.1項「スクリプトを使用したOracle Business Intelligenceのメタデータの抽出」の説明を参照してください。

5. ODIでデータ系統ロード計画を実行して、データ系統ウェアハウスの表をロードします。第6.4.2項「データ系統ロード計画の実行と監視」の説明を参照してください。この手順によって、データ系統ウェアハウスの表に対するロードが行われます。

6.3 データ系統ダッシュボードを設定するためのタスク

この項では、データ系統ダッシュボードを設定するための詳細なタスクについて説明します。内容は次のとおりです。

- 第6.3.1項「設定手順: ODIトポロジおよびロード計画の構成」

- 第6.3.2項「設定手順: RPDおよびプレゼンテーション・カタログの抽出スクリプトの構成」

- 第6.3.3項「設定手順: データ系統ウェアハウスの表の作成」

注意: この項のタスクは、第6.2項「データ系統の設定」で説明されている順序で実行する必要があります。

6.3.1 設定手順: ODIトポロジおよびロード計画の構成

ダッシュボードの5つのソースからのデータ系統データの抽出をサポートするため、ODI作業リポジトリには必要なトポロジおよび環境の設定があらかじめ構成されています。初期設定時に、抽出されたメタデータ・ファイルへのアクセスを提供するための事前作成されているデータ系統ホーム・ディレクトリ変数を構成し、アダプタ・リストの変数を構成し、事前作成されているODIおよびODIトポロジ内のConfiguration Managerソースを構成します。これにより、ODIとConfiguration Managerはデータ系統ETLの実行時のソースとなることができます。

1. ODI Studioで、データ系統抽出およびロードのロード計画を開きます。

2. 「ステップ」を選択し、DATA_LINEAGEルート・ステップを選択します。

3. プロパティ・インスペクタで、DL_HOME変数を$ORACLE_BI_HOME/biapps/DataLineageに設定します。

4. 最大8個のアダプタを移入することによってADAPTOR_LIST変数を設定します。9個以上のアダプタが必要な場合は、ADAPTOR_LIST1変数を使用してさらに最大8個のアダプタを追加できます。
お使いのソース・システムに基づいて、次のリストから1つ以上の値を選択できます。'SDE_ORA11510_Adaptor'、'SDE_ORAR1212_Adaptor'、'SDE_PSFT_90_Adaptor'、'SDE_OP_V1_Adaptor'、'SDE_ORAR1211_Adaptor'、'SDE_PSFT_91_Adaptor'、'SDE_SBL_822_Adaptor'、'SDE_SBL_811_Adaptor'、'SDE_ORAR12_Adaptor'、'SDE_ORAR1213_Adaptor'、'SDE_JDEE1_91_Adaptor'、'SDE_JDEE1_90_Adaptor'、'SDE_Universal_Adaptor'、'SDE_FUSION_V1_Adaptor'。

5. ODI Studioのトポロジ・ナビゲータのツリー・ビューの物理アーキテクチャ・ビューで、ODI作業リポジトリをホストするテクノロジを展開し、事前作成されているBIAPPS_ODIREPデータ・サーバーを見つけます。

6. そのデータ・サーバーをダブルクリックし、エディタでサーバーの接続の詳細を確認するか、または正しい詳細を入力します。インスタンス名および適切な特権が与えられたODIユーザーとパスワードが確認すべき詳細です。

7. エディタの「JDBC」タブでJDBCドライバを確認します。接続用の有効なJDBC URLが設定されているかを確認し、必要に応じて有効なJDBC URLを指定します。

8. 「テスト接続」をクリックし、入力した接続の詳細が正しいことを確認します。

9. 前述の手順を繰り返して、次の項目を構成します。

- FILE_BIAPPS_DL_DEFAULT: 入力ファイルが配置されているファイルの場所に接続します。

- BIAPPS_DW: データ・ウェアハウスに接続します。

- BIAPPS_BIACOMP: Configuration Managerのスキーマに接続します。

10. Fusion EARファイルを$ORACLE_BI_HOME/biapps/DataLineageから$DL_HOMEにコピーします。

6.3.2 設定手順: RPDおよびプレゼンテーション・カタログの抽出スクリプトの構成

この手順では、抽出スクリプトを収容するためのODIメモリー・ヒープ・サイズを設定します。また、データ系統ウェアハウスの表のロード時にソースとなるRPDおよびプレゼンテーション・カタログ・メタデータ・ファイルを生成する抽出スクリプトをカスタマイズします。

1. 適切なヒープ・サイズを設定します。Windowsでこれを行う手順は次のとおりです。
Windowsでこれを行うには、<DOMAIN_HOME>/bin/setDomainEnv.shファイルを編集用に開きます。if NOT "%USER_MEM_ARGS%"=="" (という行を探し、その行の前に次のコードを追加します。

if "%SERVER_NAME%"=="odi_server1" (
set USER_MEM_ARGS=-Xms512m -Xmx3072m -XX:PermSize=256m
-XX:MaxPermSize=512m
)

Linuxでこれを行うには、<DOMAIN_HOME>/bin/setDomainEnv.cmdファイルを編集用に開きます。if [ "${USER_MEM_ARGS}" != "" ] ; thenという行を探し、その行の前に次のコードを追加します。

if [ "${SERVER_NAME}" = "odi_server1" ] ; then
USER_MEM_ARGS="-Xms512m -Xmx3072m -XX:PermSize=256m -XX:MaxPermSize=512m"
export USER_MEM_ARG
fi

2. $DL_HOMEにあるwebCatExtractスクリプトを開きます。

3. OBIEE_INSTANCE_HOMEをOracle BI EEインスタンスのホームの場所に設定します。

4. OBIEE_WEBCATをOracle BI Applicationのプレゼンテーション・カタログの場所に設定します。

5. TARGET_DIRを、抽出されたメタデータ・ファイル(webcat_text.txtおよびwebcat_dashboard_test.txt)が作成される場所に設定します。

6. ファイルを保存して閉じます。

7. webCatExtract_dashboardスクリプトを開き、前述のように変数OBIEE_INSTANCE_HOME、OBIEE_WEBCATおよびTARGET_DIRを設定します。

8. ファイルを保存して閉じます。

9. rpdExractスクリプトを開き、OBIEE_ORACLE_HOMEを、Oracle BI EEインスタンスのホームの場所、およびプレゼンテーション・カタログとリポジトリの場所に設定します。

10. OBIEE_ORACLE_HOMEをOracle BI EEインスタンスのホームの場所に設定します。

11. OBIEE_RPDをOracle BI EEのリポジトリの名前および場所に設定します。

12. TARGET_DIRを、抽出されたメタデータ・ファイル(rpd_text.txt)が作成される場所に設定します。

13. ファイルを保存して閉じます。

6.3.3 設定手順: データ系統ウェアハウスの表の作成

この手順では、Generate DataLineage DDLパッケージを使用して、ウェアハウス内にデータ系統の表を作成します。これらの表はデータ・ウェアハウスの作成時にデフォルトで作成されますが、このパッケージを使用していつでも作成できます。

1. ODI Studioデザイナ・ナビゲータで、「BIアプリケーション・プロジェクト」→「コンポーネント」→「DW DDLの生成」→「パッケージ」を展開します。

2. Generate DataLineage DDLパッケージを実行し、オペレータを使用して実行状況を監視します。

6.4 データ系統ダッシュボードをロードおよびリフレッシュするためのタスク

この項では、最初に行う、および継続的に行うデータ系統ダッシュボードのロードと更新の詳細なタスク、およびそれらで必要となるメタデータについて説明します。内容は次のとおりです。

- 第6.4.1項「スクリプトを使用したOracle Business Intelligenceのメタデータの抽出」

- 第6.4.2項「データ系統ロード計画の実行および監視」

注意: この項のタスクは、第6.2項「データ系統の設定」で説明されている順序で実行する必要があります。

6.4.1 スクリプトを使用したOracle Business Intelligenceのメタデータの抽出

この手順では、メタデータ抽出スクリプトをコピーして実行し、出力ファイルをデータ系統のホーム・ディレクトリにコピーします。メタデータ抽出スクリプトを実行してメタデータをリフレッシュできます。

1. Oracle Business Intelligence Enterprise EditionがインストールされているWindowsマシンにスクリプトをコピーし、実行します。

2. スクリプト内のTARGET_DIR変数で指定された場所に次のファイルが生成されていることを確認します。

- WebCat_text

- Webcat_dashboard_text

- rpd_text

これらのファイルには、抽出されたプレゼンテーション・カタログおよびリポジトリ・メタデータが含まれており、データ系統ウェアハウスの表のロード時のソースとなります。

3. スクリプト実行によって出力されたファイルをTARGET_DIRの場所から$DL_HOMEにコピーします。

4. Fusion EARファイルを$ORACLE_BI_HOME/biapps/DataLineageから$DL_HOMEにコピーします。

6.4.2 データ系統ロード計画の実行および監視

この手順では、ODIの中でデータ系統抽出およびロードのロード計画を実行します。このロード計画は、ソースとして構成および生成されたソースおよび抽出されたメタデータ・ファイルを使用して、事前作成されているデータ系統ウェアハウスの表へのロードおよびリフレッシュを行います。

1. ODI Studioデザイナ・ナビゲータで、「ロード計画とシナリオ」→「事前定義されたロード計画」→「データ系統」を展開します。

2. データ系統抽出およびロードのロード計画を実行し、オペレータを使用して実行状況を監視します。

6.5 データ系統ダッシュボードを使用した分析の実行

この項では、BI Applicationsデータ系統ダッシュボードの概要、およびOracle Business Intelligence Applicationsでのその使用事例を示します。この項の内容は次のとおりです。

- 第6.5.1項「Oracle BI Applicationsデータ系統ダッシュボードの概要」

- 第6.5.2項「Oracle Business Intelligence Applicationsのためのデータ系統の分析」

6.5.1 Oracle BI Applicationsデータ系統ダッシュボードの概要

OBIA DataLineageダッシュボードの「DataLineage要約」ページ内の次のダッシュボード・プロンプトを使用して、Oracle BI Applicationsの様々なエンティティでデータ系統が分析されます。

- ダッシュボード名

- レポート名

- プレゼンテーション表名

- プレゼンテーション列名

- 論理表名

- 論理列名

- 倉庫データストア・リソース名

- 倉庫列名

- ソース・アプリケーション

- ソース表名

- ソース列名

任意のレベルのダッシュボード・プロンプトの値を選択でき、以降の選択は他の選択によって制約を受けます。たとえば、「レポート名」プロンプトでなんらかの選択を行うと、「論理表名」プロンプトの選択は選択済のレポートに含まれる内容に制限されます。

OBIAデータ系統ダッシュボードには5つのページがあります。その中の要約の表形式の結果については、詳細ページで詳しいデータ系統を確認できます。次のページがあります。

- DataLineage要約: 物理関係および論理関係に関するエンドツーエンドのデータ系統の要約レポートを提供します。要約レポート内のエンティティに関する詳細なレポートおよびダッシュボード・ページに移動するには、そのリンクをクリックします。

- ダッシュボード実装: 選択されたダッシュボードに関して、次のレポートの詳細を示します。ダッシュボード・ページ、レポートおよびプレゼンテーション列。プレゼンテーション・カタログ、表および列。RPD実装、OBAWの物理列からプレゼンテーション列を導出する方法の詳細。

- レポート実装: 選択したレポートに関して、基礎となる物理列からプレゼンテーション列を導出する方法の詳細を示します。また、ウェアハウスの表を記述するレポートや、OLTPソースからステージング表へ、およびステージング表からウェアハウスのディメンション表やファクト表へロードするODIインタフェースやアダプタのリストを示すレポートも含まれます。

- プレゼンテーション・レイヤー実装: 選択されたプレゼンテーションの表および列に関して、RPD内での論理列と物理列の導出の詳細を示します。また、ウェアハウスの表を記述するレポートや、OLTPソースからステージング表へ、およびステージング表からウェアハウスのディメンション表やファクト表へロードするODIインタフェースやアダプタのリストを示すレポートも含まれます。

- 倉庫実装: 選択されたウェアハウスの表名と列名に関して、ウェアハウスのデータ・ストア、およびそのOLTPソースの表と列の要約を示します。また、OLTPソースからステージング表へ、およびステージング表からウェアハウスのディメンション表やファクト表へロードするODIインタフェースやアダプタのリストを示すレポートも含まれます。

6.5.2 Oracle Business Intelligence Applicationsのためのデータ系統の分析

この項では、OBIAデータ系統ダッシュボードのレポートおよび使用例を示すために、1つの使用シナリオを取り上げます。

Oracleビジネス・アプリケーションのデータ系統を分析するには:

1. OBIAデータ系統ダッシュボードに移動します。

2. 「DataLineage要約」ページで、利用可能なプロンプトから選択します。プロンプトから複数選択できますが、利用可能なプロンプトの選択は前に行った他のプロンプトの選択によって制約を受けます。

3. 「適用」をクリックして「OBIA-LineageSummary」レポートを表示します。このレポートは、プレゼンテーション・ダッシュボードおよびレポートから、BI Applicationsリポジトリ・メタデータを経由し、最終的にウェアハウスの表および列に至るまでの系統の詳細を示します。

4. ダッシュボードの「ダッシュボード実装」ページで詳細なレポートへドリルするには、サマリー・レポートで「ダッシュボード名」の値をクリックします。これにより「ダッシュボード実装」ページが開かれ、「ダッシュボード名」のダッシュボード・プロンプトに、ダッシュボード名があらかじめ選択されています。レポート内の他のエンティティをクリックして他のページに移動することもできます。たとえば、「倉庫列名」をクリックし、「実装」を選択すると、ETLの実装に焦点を当てた「倉庫実装」ページに移動します。「ダッシュボード実装」ページでレポートを確認してください。
「ダッシュボード実装」ページでレポートを確認するには:

- このページの最初のレポートである「DashboardImplementation-OBIA-LineageSummary」は、デフォルトの「LineageSummary」レポートと同様の系統を示します。このレポートでは、ダッシュボードからプレゼンテーション・カタログを経由し、ウェアハウスの表と列に至るまでの系統を追跡します。

- 2つ目のレポートである「DashboardImplementation-DashboardDetails」は、ダッシュボードのみに焦点を当てます。ダッシュボードのページ、レポート、プレゼンテーション・カタログ、および関連するプレゼンテーションの表と列の名前に関する詳細情報が示されます。

- 3つ目のレポートである「DashboardImplementation-OBIA-RPDImplementation」は、BIリポジトリ・メタデータ内のデータの系統に焦点を当てます。プレゼンテーション・カタログの名前から始まり、ビジネス・モデルおよび論理表と列の名前を経由し、物理的なカタログ、表、列の名前に至るまで、3つのリポジトリのレイヤーをすべてカバーします。論理レイヤーの詳細には式が含まれます。これは、単に表および列のリソースの論理式である場合が多くあります。

- 4つ目のレポートである「DashboardImplementation-ODIImplementation-SourceToStaging」は、ウェアハウスのステージング表のロードで使用されるETLインタフェースに焦点を当て、ウェアハウスの表と関連するアダプタおよびインタフェースの詳細を示します。

- 5つ目のレポートである「DashboardImplementation-ODIImplementation-StagingToWarehouse」は、ウェアハウスのターゲットとなるファクト表およびディメンション表のロードで使用されるETLインタフェースに焦点を当て、ウェアハウスの表と関連するアダプタおよびインタフェースの詳細を示します。

5. 「DataLineage要約」ページに戻り、「レポート名」の値をクリックし、「レポート実装」を選択し、「レポート実装」ページのダッシュボード・プロンプトの値としてそのレポートを開きます。レポートをスクロールしてこのページを表示します。これらのレポートがダッシュボード用に提供されているレポートとほぼ同じであることに注目してください。

6. 「プレゼンテーション・レイヤー実装」ページに移動します。このページには、RPDでプレゼンテーションの列に導出される論理列および物理列の詳細に関するレポートが含まれます。また、ウェアハウスの表を記述するレポートや、OLTPソースからステージング表へ、およびステージング表からウェアハウスのディメンション表やファクト表へロードするODIインタフェースやアダプタのリストを示すレポートも含まれます。

7. 「倉庫実装」ページに移動します。ここでは、「WarehouseImplementation-OBIA-LineageSummary」レポートによって、ウェアハウスの表と列とそれに関連するモデル、およびソースのトランザクションの表と列の間の関係の要約が示されます。

索引
A  C  D  E  F  H  I  L  M  N  O  P  R  S  T  U  W

A

集計表

データ・ウェアハウスの表, 4.2.1

C

チャート

ローカル・シード・データ、インポート, 3.1.1.2

翻訳表、メンテナンスのプロセス, 3.1

W_LOCALIZED_STRING_G表、カスタム翻訳の追加, 3.1.3

Webカタログ文字列、翻訳について, 3.2

モジュール間構成、実行

ディメンション・キー、解決, 1.5.1.1, 1.6.1.1

ロード、構成, 1.4.3

CSVファイル

デリミタ, 1.4.2.2

通貨換算, 4.10 カスタマイズ, 1.1.3

索引の追加, 1.5.2

パッチ・インストール, 1.1.3

カテゴリ1, 1.2

カテゴリ2, 1.3

カテゴリ3, 1.4

概要, 1.1

ストアド・ルックアップ, 1.5.1

D

データ・ウェアハウスの言語

ベース言語およびインストール済言語の構成, 2.1

データ・ウェアハウスの表

集計表, 4.2.1

ディメンション・クラス表, 4.2.2

ディメンション表, 4.2.3

ファクト表, 4.2.5

ヘルパー表, 4.2.6

階層表, 4.2.7

内部表, 4.3

ミニ・ディメンション表, 4.2.8

命名規則, 4.1

プライマリ・データ値, 4.8

ステージング表, 4.2.9

列の標準接頭辞, 4.4

サポートされる値リスト, 4.9

システム列, 4.6

表のタイプ, 4.2

翻訳表, 4.2.10

デリミタ

CSVファイル, 1.4.2.2

ディメンション・クラス表

データ・ウェアハウスの表, 4.2.2

ディメンション表

ビジネス・ロール・ベースのフラグ, 4.2.4

データ・ウェアハウスの表, 4.2.3

ディメンション

キーの解決、ルックアップを使用, 1.5.1.1.1, 1.6.1.1.1

キー、解決, 1.5.1.1, 1.6.1.1

E

抽出、構成

追加データの抽出、概要, 1.4.2.1

新しいソース表からのデータの抽出, 1.4.2.1.2

既存のソース表からの新しいデータの抽出, 1.4.2.1.1

F

ファクト表

データ・ウェアハウスの表, 4.2.5

H

ヘルパー表

データ・ウェアハウスの表, 4.2.6

階層表

データ・ウェアハウスの表, 4.2.7

I

内部表, 4.3

L

ロード、構成

概要, 1.4.3

M

メタデータ

文字列の外部化, 3.1.2

ミニ・ディメンション表

データ・ウェアハウスの表, 4.2.8

複数言語サポート

BI Applicationsのドメインについて, 2.3

ディメンション翻訳表について, 2.4

擬似翻訳について, 2.2

概要, 2.1

翻訳表, 2.1

N

命名規則

データ・ウェアハウスの表, 4.1

O

Oracle BIのチャート

メタデータ文字列、外部化, 3.1.2

Oracle BIのシード・データ、英語以外のロケールの更新, 3.1.1

Oracle BIのプレゼンテーション・レイヤー

翻訳表のメンテナンスのプロセス, 3.1

Oracle BIリポジトリ

メタデータ文字列の外部化, 3.1.2

Oracle BIのシード・データ

英語以外のロケールの更新, 3.1.1

P

パッチ・インストール

カスタマイズに対する影響, 1.1.3

プライマリ抽出マッピングおよび削除マッピング

ソースがアーカイブしたレコード、削除の構成, 1.4.3.2.1

作業, 1.4.3.2

プライマリ抽出マッピングおよび削除マッピング

理解, 1.4.3.1

作業, 1.4.3.2

R

レコード

フィルタリングおよび削除, 1.4.3.1, 1.4.3.2

ソースがアーカイブしたレコード、削除の構成, 1.4.3.2.1

ロードマップ

カスタマイズ, 1

S

シード・データ

インポート, 3.1.1.2

ソースがアーカイブしたレコード

削除の構成, 1.4.3.2.1

ステージング表

データ・ウェアハウスの表, 4.2.9

列の標準接頭辞, 4.4 列の標準接尾辞, 4.5 文字列翻訳

メタデータ用に追加, 3.1.3.1

システム列, 4.6

複数通貨コード, 4.7

T

表のタイプ

データ・ウェアハウスの表, 4.2

トランザクション・データベース

ロケール・シード・データのインポート, 3.1.1.2

翻訳表

データ・ウェアハウスの表, 4.2.10

メンテナンスのプロセス, 3.1

U

Unicode

ローカル・シード・データ、インポート, 3.1.1.2

メタデータ文字列、外部化, 3.1.2

Oracle BIのシード・データ、英語以外のロケールの更新, 3.1.1

文字列翻訳、メタデータ用に追加, 3.1.3.1

翻訳表、メンテナンスのプロセス, 3.1

W_LOCALIZED_STRING_G表、カスタム翻訳の追加, 3.1.3

Webカタログ文字列、翻訳について, 3.2

W

W_LOCALIZED_STRING_G表、カスタム翻訳の追加, 3.1.3

Webカタログ文字列

翻訳について, 3.2

作業リポジトリ

カスタマイズおよびパッチ適用, 1.1.3

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。