Communications Data Model 実装およびオペレーション・ガイド

リリース11.3.1

B70212-01(原本部品番号:E28442-03)

目次

例一覧

図一覧

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

はじめに

- 対象読者

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

- 関連Oracleリソース

- 表記規則

1 Oracle Communications Data Modelのカスタマイズの概要

- Oracle Communications Data Modelの概要

- Oracle Communications Data Modelのコンポーネント

- Oracle Communications Data Modelを構成するOracle製品

- Oracle Communications Data Modelウェアハウスを実装する手順

- Oracle Communications Data Modelのカスタマイズを開始する前に

- 実装者の前提知識

- データ・ウェアハウス管理委員会の責任

- Oracle Communications Data Modelのメタデータの管理

- メタデータのカテゴリおよび規格

- メタデータ・リポジトリの操作

- Oracle Communications Data Modelで提供されるメタデータ・リポジトリの参照

- Oracle Communications Data ModelでのOracle Warehouse Builderの使用

- Oracle Communications Data Modelのフィットギャップ分析の実行

2 物理モデルのカスタマイズ

- デフォルトの物理モデルの特性

- Oracle Communications Data Model物理モデルのカスタマイズ

- 物理モデルをカスタマイズする前に答える質問

- 物理モデルをカスタマイズする場合の規則

- 基盤レイヤーのカスタマイズ

- 一般的な変更シナリオ

- 物理構造を設計する場合の一般的な推奨事項

- Oracle Communications Data Modelの表領域

- Oracle Communications Data Modelのデータ圧縮

- 使用できるデータ圧縮のタイプ

- Oracle Communications Data Modelのスーパータイプおよびサブタイプ・エンティティの表

- 物理モデルのサロゲート・キー

- Oracle Communications Data Modelの整合性制約

- Oracle Communications Data Modelの索引とパーティション索引

- Oracle Communications Data Modelのパーティション表

- 管理性のためのOracle Communications Data Modelのパーティション化

- 簡単なデータ・アクセスのためのOracle Communications Data Modelのパーティション化

- 結合パフォーマンスのためのOracle Communications Data Modelのパーティション化

- Oracle Communications Data Modelのパラレル実行

- セッションのパラレル実行の有効化

- DML操作のパラレル実行の有効化

- 表レベルでのパラレル実行の有効化

3 アクセス・レイヤーのカスタマイズ

- Oracle Communications Data Modelのアクセス・レイヤーのカスタマイズの概要

- Oracle Communications Data Modelの導出表

- 計算データの新しい導出表の作成

- Oracle Communications Data Modelデータ・マイニング・モデルのカスタマイズ

- Oracle Communications Data Modelの新しいデータ・マイニング・モデルの作成

- Oracle Communications Data Modelデータ・マイニング・モデルの変更

- チュートリアル: チャーン予測モデルのカスタマイズ

- Oracle Communications Data Modelの集計表

- Oracle Communications Data Modelの次元コンポーネント

- 次元モデルの特性

- リレーショナル・スターおよびスノーフレーク表の特性

- リレーショナル・ディメンション表の宣言

- リレーショナル・ディメンション表の検証

- OLAP次元モデルの特性

- Oracle OLAPキューブ・ビュー

- キューブ・マテリアライズド・ビュー

- Oracle Communications Data ModelのOLAPキューブの特性

- Oracle Communications Data Modelの新しいOLAPキューブの定義

- Oracle Communications Data ModelのOracle OLAPキューブの変更

- Oracle Communications Data Modelの予測キューブの作成

- Oracle Communications Data Modelのキューブ・パーティション化戦略の選択

- Oracle Communications Data Modelのキューブ・データのメンテナンス方法の選択

- Oracle Communications Data Modelのマテリアライズド・ビュー

- マテリアライズド・ビューのタイプおよびリフレッシュ・オプション

- 集計を含むマテリアライズド・ビューのリフレッシュ・オプション

- 結合のみを含むマテリアライズド・ビューのリフレッシュ・オプション

- ネステッド・マテリアライズド・ビューのリフレッシュ・オプション

- マテリアライズド・ビューに対する索引付けの選択

- パーティション化とマテリアライズド・ビュー

- マテリアライズド・ビューの圧縮

4 ETLの実装およびカスタマイズ

- Oracle Communications Data ModelのETLのロール

- Oracle Communications Data Modelウェアハウスの基盤レイヤーのETL

- アプリケーション・アダプタを使用した基盤レイヤーの移入

- 固有のSource-ETLの書込み

- Source-ETLの設計上の考慮事項

- Oracle Communications Data ModelのSource-ETLのETLアーキテクチャ

- Source-ETLのソースとターゲット・マッピング・ドキュメントの作成

- Source-ETLのデータ品質問題を解決する計画の設計

- Source-ETLワークフローおよびジョブ制御の設計

- Source-ETL例外処理の設計

- 効率的にロードするSource-ETLの書込み

- Oracle Communications Data ModelのIntra-ETLのカスタマイズ

- Oracle Communications Data Modelウェアハウスの初期ロードの実行

- 基盤レイヤーの初期ロードの実行

- アクセス・レイヤーの初期ロードの実行

- デフォルトのOracle Communications Data ModelのIntra-ETLの実行

- Oracle Communications Data Modelウェアハウスのデータのリフレッシュ

- Oracle Communications Data Modelウェアハウスの基盤レイヤーのリフレッシュ

- Oracle Communications Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ

- Oracle Communications Data Modelの導出表および集計表のリフレッシュ

- Oracle Communications Data ModelのOLAPキューブのリフレッシュ

- Oracle Communications Data Modelデータ・マイニング・モデルのリフレッシュ

- Oracle Communications Data ModelのIntra-ETL実行中のエラーの管理

- Intra-ETLプロセスの実行の監視

- Intra ETLプロセスのリカバリ

- Intra-ETLのパフォーマンスのトラブルシューティング

- 実行計画のチェック

- PARALLEL DML実行の監視

- データ・マイニング・モデルの作成のトラブルシューティング

5 レポートおよび問合せのカスタマイズ

- Oracle Communications Data Modelのレポート・アプローチ

- Oracle Communications Data Modelサンプル・レポートのカスタマイズ

- 問合せとレポートの作成

- スター・クエリーの最適化

- Oracle Communications Data Modelレポート・パフォーマンスのトラブルシューティング

- As IsおよびAs Was問合せの書込み

- As Is問合せの特性

- As Was問合せの特性

- 例: Oracle Communications Data ModelのAs IsおよびAs Was問合せ

- チュートリアル: 新しいOracle Communications Data Modelダッシュボードの作成

- チュートリアル: 新しいOracle Communications Data Modelレポートの作成

A Oracle Communications Data Modelウェアハウスのサイズ設定および構成

- Oracle Communications Data Modelウェアハウスのサイズ設定

- Oracle Communications Data Modelのバランスのとれたシステムの構成

- Oracle Communications Data Modelウェアハウスの高いスループットの維持

- 容量ではなくバンド幅のOracle Communications Data ModelのI/Oの構成

- Oracle Communications Data Modelの拡張計画

- ウェアハウスを作成する前のI/Oシステムのテスト

- Oracle Communications Data Modelのバランスのとれたハードウェア構成のガイドライン

B Oracle Communications Data Modelのユーザー権限の操作

- Oracle Communications Data Modelに作成されるアカウント

- Oracle Communications Data Modelのユーザー権限を考慮する必要がある場合

- サンプル・レポートのユーザーへのSELECT権限のみの付与

C Oracle Communications Data ModelのNCCアダプタの使用

- Oracle Communications Data ModelのNCCアダプタの概要

- Oracle Communications Data ModelのNCCアダプタで使用されるデータベース・スキーマ

- Oracle Data Integrator

- Oracle GoldenGate

- Oracle Communications Data ModelのNCCアダプタを使用したウェアハウスの移入

- Oracle Communications Data ModelのNCCアダプタを使用した初期ロード

- Oracle Communications Data ModelのNCCアダプタを使用したデータのリフレッシュ

- スケジュール単位の基盤レイヤーのリフレッシュ

- リアルタイム・データによる基盤レイヤーのリフレッシュ

- Oracle Communications Data ModelのNCCアダプタの実行フロー

- アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー

- ODIのみによるアダプタを使用した場合の実行フロー

- Oracle Communications Data ModelのNCCアダプタのコンポーネント

- NCCソース・スキーマ・オブジェクト

- Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義

- ncc_stgスキーマ・オブジェクト

- ocdm_sysスキーマに追加される定義

- NCC_OCDMプロジェクト

- SRC_STG_NONAGGフォルダ

- STG_OCDMフォルダ

- NCCアダプタによって入力されるOracle Communications Data Modelの表および列

D Oracle Communications Billing and Revenue Managementアダプタの使用

- Oracle Communications Data ModelのBRMアダプタの概要

- Oracle Communications Data ModelのBRMアダプタのコンポーネント

- BRMソース・スキーマ表

- Oracle Communications Data ModelのBRMアダプタのデータベース・スキーマ

- Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義

- Oracle Communications Data ModelのBRMアダプタのステージング・スキーマ・オブジェクト

- Oracle Communications Data ModelのBRMアダプタのOCDM_SYSオブジェクト

- Oracle Data Integrator

- Oracle GoldenGate Replication

- Oracle Communications Data ModelのBRMアダプタの実行フロー

- BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)

- BRMアダプタを使用した実行フロー: Oracle GoldenGateおよびODIを使用

- Oracle Communications Data ModelのBRMアダプタを使用したウェアハウスの移入

- Oracle Communications Data ModelのBRMアダプタを使用した初期ロード

- Oracle Communications Data ModelのBRMアダプタを使用したデータのリフレッシュ(チェンジ・データ・キャプチャ: CDC)

- スケジュール単位の基盤レイヤーのリフレッシュ

- リアルタイム・データによる基盤レイヤーのリフレッシュ

- ODI BRM_OCDMプロジェクト

- BRM_OCDMプロジェクトのSRC_STG_NONOGGフォルダのオブジェクト

- SRC_STG_LOAD_NON_OGG_PKGパッケージ

- BRM_OCDMのSTG_OCDMフォルダのオブジェクト

- STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージ

- Oracle GoldenGateプロセスの確認

E Oracle Communications Data Modelのアップグレード

- Oracle Communications Data Modelのアップグレードの準備

- Oracle Communications Data Modelのアップグレード・パス

- Oracle Communications Data Modelの回帰テスト

索引

例一覧

- 2-1 Oracle Communications Data Modelの圧縮表の作成

- 3-1 Oracle Communications Data Modelのマイニング・モデルへの新しい列の追加

- 3-2 Oracle Communications Data Modelネステッド・マテリアライズド・ビューのリフレッシュ

- 4-1 パーティション表でのパーティション交換文の使用

- 4-2 Oracle Communications Data ModelのORA-20991エラーのトラブルシューティング

- 4-3 メッセージはありません... [言語=ZHS]エラーのトラブルシューティング

- 4-4 Oracle Communications Data ModelのORA-40113エラーのトラブルシューティング

- 4-5 Oracle Communications Data ModelのORA-40112エラーのトラブルシューティング

- 4-6 Oracle Communications Data ModelのORA-11130エラーのトラブルシューティング

- 5-1 Oracle Communications Data Modelのリレーショナル問合せの作成

- 5-2 スター型変換

- 5-3 Oracle Communications Data Modelレポートのトラブルシューティング

- 5-4 レポートのトラブルシューティング: 表がありません

- 5-5 レポートのトラブルシューティング: データベースが接続されていない場合

- 5-6 婚姻区分で分割された収税のAs Is問合せ

- 5-7 婚姻区分で分割された収税のAs Was問合せ

- 5-8 郡で分割された収税データのAs Is問合せ

- 5-9 郡で分割された収税データのAs Was問合せ

図一覧

- 2-1 Oracle Communications Data Modelウェアハウスのレイヤー

- 2-2 結合パフォーマンスのパーティション化

- 2-3 2つの表間のフル・パーティション・ワイズ結合のパラレル実行

- 2-4 パーシャル・パーティション・ワイズ結合

- 3-1 スター・スキーマ・ダイアグラム

- 3-2 OLAPの次元モデルの図

- 4-1 ETLフロー・ダイアグラム

- C-1 Oracle GoldenGateでアダプタを使用する場合の実行フロー

- C-2 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー

- D-1 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー

- D-2 Oracle GoldenGateでBRMアダプタを使用する場合の実行フロー

Oracle® Communications Data Model

実装およびオペレーション・ガイド

リリース11.3.1

B70212-01(原本部品番号:E28442-03)

2012年4月

Oracle Communications Data Model実装およびオペレーション・ガイド リリース11.3.1

B70212-01

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

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

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

はじめに

『Oracle Communications Data Model実装およびオペレーション・ガイド』は、Oracle Communications Data Modelに基づいてデータ・ウェアハウスを実装するベスト・プラクティスを示します。

「はじめに」の内容は次のとおりです。

- 対象読者

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

- 関連Oracleリソース

- 表記規則

対象読者

このドキュメントは、Oracle Communications Data Modelウェアハウスを実装するビジネス・アナリスト、データ・モデラー、データ・ウェアハウス管理者、ITスタッフおよびETL開発者を対象としています。

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

オラクル社のアクセシビリティへの取組みの詳細は、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リソース

Oracle Communications Data Modelを実装する場合の多くのリソースが用意されています。

Oracle Communications Data Modelドキュメント・セット

Oracle Communications Data Modelの詳細は、Oracle Communications Data Modelリリース11gドキュメント・セットの次のドキュメントを参照してください。

- 『Oracle Communications Data Modelインストレーション・ガイド』

- 『Oracle Communications Data Modelリファレンス』

- 『Oracle Communications Data Modelリリース・ノート』

Oracle Technology Network

Oracle Technology Network(OTN)を訪問して、デモ、ホワイトペーパー、Oracle By Example(OBE)チュートリアル、更新されたOracleドキュメントおよび他の付帯資料にアクセスします。

OTNの登録

OTNを使用するには、オンラインでの登録が必要です。登録は、次のWebサイトから無償で行えます。

www.oracle.com/technetwork/index.html

OTNのOracleドキュメント

OTNのOracleドキュメント・サイトを使用して、Oracleドキュメントにアクセスできます。すでにOTNのユーザー名およびパスワードを取得している場合は、次のURLでOTN Webサイトのドキュメントのセクションに直接接続できます。

www.oracle.com/technetwork/indexes/documentation/index.html

OTNのOracle Learning Library

Oracle Learning Libraryは、無償のオンライン・トレーニング・コンテンツ(OBE、デモおよびチュートリアル)を提供します。すでにOTNのユーザー名およびパスワードを取得している場合は、次のURLでOracle Learning Library Webサイトに直接接続できます。

www.oracle.com/technetwork/tutorials/index.html

チュートリアルまたはデモ("All"内)を名前で検索できます。

たとえば、"All"内で"OCDMTutorial"を検索すると、Oracle Communications Data Modelのチュートリアルに移動します。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

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

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

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

1 Oracle Communications Data Modelのカスタマイズの概要

この章では、Oracle Communications Data Modelのカスタマイズの概要を示します。内容は次のとおりです。

- Oracle Communications Data Modelの概要

- Oracle Communications Data Modelウェアハウスを実装する手順

- Oracle Communications Data Modelのカスタマイズを開始する前に

- Oracle Communications Data Modelのメタデータの管理

- Oracle Communications Data Modelのフィットギャップ分析の実行

Oracle Communications Data Modelの概要

Oracle Communications Data Modelは、標準ベースの事前構築済の通信データ・ウェアハウスを提供して、通信事業者がインサイト(真相を見抜く力)を持ち、より迅速に行動することを可能します。Oracle Communications Data Modelでは、即時利用可能なOracleベースのデータ・ウェアハウスおよびビジネス・インテリジェンス・ソリューションを利用することで、即時の運用および継続的な運用においてコストを削減し、通信業界特有のデータ・モデルを最高水準のデータベースおよびビジネス・インテリジェンス・テクノロジ・ソリューションで利用できます。アプリケーション環境でOracle Communications Data Modelを使用できます。また、簡単にモデルを拡張できます。

Oracle Communications Data Modelを使用して、Oracle Communications Data Modelの設計および実装を速やかに開始し、予測どおりの実装作業により、データ・ウェアハウスおよびビジネス・インテリジェンス・プロジェクトのポジティブROIを速やかに達成できます。

Oracle Communications Data Modelでは、通信ビジネス・インテリジェンス・ソリューションに対して行う必要のあるデータ・モデリング作業の多くが提供されます。通信サービス・プロバイダのベスト・プラクティスに従って、Oracle Communications Data Model論理および物理データ・モデルが設計されました。Oracle Communications Data Modelは、『Oracle Communications Data Modelリファレンス』に示すように、TMフォーラムの情報フレームワーク(SID)バージョン8.1によって準拠が認定されています。

- Oracle Communications Data Modelのコンポーネント

- Oracle Communications Data Modelを構成するOracle製品

Oracle Communications Data Modelのコンポーネント

Oracle Communications Data Modelには、次のコンポーネントがあります。

- 第3正規形(3NF)エンティティ・オブジェクト標準ベース・モデルの論理モデル。論理モデルは『Oracle Communications Data Modelリファレンス』で説明されています。

- 2つのOracle Databaseスキーマとして定義される物理モデル。1つのスキーマは、Oracle Communications Data ModelのすべてのリレーショナルおよびOLAP物理コンポーネントおよびデータ・マイニング・モデルの結果を保持する表を定義します。もう1つのスキーマは、実際のデータ・マイニング・モデルを定義します。

- Oracle Communications Data Model 3NF物理表からOracle Communications Data Modelの導出表および集計表にデータを抽出、変換およびロード(ETL)するIntra-ETLデータベース・パッケージおよびSQLスクリプト。

- Oracle Business Intelligence Suite Enterprise Editionを使用して開発したサンプル・レポートおよびダッシュボード。

- DDLおよびインストール・スクリプト

注意:
Oracle Installerを使用してOracle Communications Data Modelをインストールする場合、2つの異なるタイプのインストールの実行を選択できます。

- Oracle Communications Data Modelコンポーネント自体のインストール

- サンプル・レポート(およびスキーマ)のインストール

異なるタイプのインストールの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

参照:
コンポーネントの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

Oracle Communications Data Modelを構成するOracle製品

いくつかのOracleテクノロジには、Oracle Communications Data Modelのインフラストラクチャの構築が含まれます。

- OLAPオプション、データ・マイニング・オプションおよびパーティション化オプションを設定したOracleデータベース

- Oracle Communications Data Modelのアプリケーション・アダプタ

- Oracle開発ツール

- Oracle Business Intelligence Suite Enterprise Editionの表示ツール

OLAP、データ・マイニングおよびパーティション化オプションが設定されたOracle Database

Oracle Communications Data Modelは、完全なOracleテクニカル・スタックを使用します。SQLモデル、圧縮、パーティション化、高度な統計機能、マテリアライズド・ビュー、データ・マイニング、オンライン分析処理(OLAP)といったOracleデータベースのデータ・ウェアハウス機能を利用します。

Oracle Communications Data Modelのアプリケーション・アダプタ

Oracle Communications Data ModelのOracle Communications Network Charging and Controlアダプタは、Oracle Communications Data Modelのオプションです。アプリケーション・アダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤーにOracle Communications Network Charging and Control(NCC)システムのデータを移入できます。

Oracle開発ツール

次のOracleツールを使用して、Oracle Communications Data Modelで提供される事前定義済の物理モデルのカスタマイズや、ターゲットのリレーショナル表とマテリアライズド・キューブ・ビューの移入を行うことができます。

表1-1 Oracle Communications Data Modelで使用するOracle開発ツール

名前

使用

SQL DeveloperまたはSQL*Plus

データベース・オブジェクトの変更、カスタマイズおよび拡張

Oracle Warehouse Builder

Intra-ETLプロセスのプロセス制御

Analytic Workspace Manager

OLAPディメンション・オブジェクトの表示、作成、開発および管理

Oracle Business Intelligence Suite Enterprise Editionの表示ツール

Oracle Business Intelligence Suite Enterprise Editionは、あらゆる分析およびレポート機能を提供するエンタープライズBI製品の包括的なスイートです。Oracle Business Intelligence Suite Enterprise EditionのAnswersおよびDashboardの表示ツールを使用して、Oracle Communications Data Modelで提供された事前定義済のサンプル・ダッシュボード・レポートをカスタマイズできます。

参照:
「Oracle Communications Data Modelのレポート・アプローチ」

Oracle Communications Data Modelウェアハウスを実装する手順

Oracle Communications Data Modelは通信サービス・プロバイダのベスト・プラクティスに従って設計されましたが、通常モデルでビジネス・ニーズを満たすカスタマイズが必要です。

Oracle Communications Data Modelをカスタマイズする理由には、ビジネスにOracle Communications Data Modelの論理モデルにあるビジネス・エリアがない場合や新規または別のビジネス・ルールを適用する必要がある場合などがあります。

通常の物理モデルの変更には、表と列の追加、削除、変更、名前変更、または外部キー、制約、索引の変更が含まれます。

Oracle Communications Data Modelウェアハウスを実装するには、次の手順に従います。

1. 「Oracle Communications Data Modelのカスタマイズを開始する前に」に記載された組織タスクを実行します。

2. 「Oracle Communications Data Modelのフィットギャップ分析の実行」に記載されたプロセスに従って、フィットギャップ分析を作成します。

3. 開発環境では、Oracle Communications Data Modelのコピーをインストールします。

4. フィットギャップ分析レポートに記載された変更を行って、Oracle Communications Data Modelをカスタマイズします。変更は、次の順序で行います。

1. 物理モデルの基盤レイヤーおよびそのレイヤーを移入するETL。物理オブジェクトをカスタマイズする場合、「基盤レイヤーのカスタマイズ」のガイドラインに従ってください。ETLを記述する場合、「Oracle Communications Data Modelウェアハウスの基盤レイヤーのETL」のガイドラインに従ってください。

2. 物理モデルのアクセス・レイヤーおよびそのレイヤーを移入するETL。物理オブジェクトを設計する場合、第3章「アクセス・レイヤーのカスタマイズ」のガイドラインに従います。ETLを書き込む場合、「Oracle Communications Data ModelのIntra-ETLのカスタマイズ」のガイドラインに従います。

5. テスト環境に、Oracle Communications Data Modelのカスタマイズしたバージョンのコピーを作成します。次に、手順2で作成したドキュメントに従い、Oracle Communications Data Modelのカスタマイズしたバージョンをテストします。

6. 通常の手順に従って、テストおよびカスタマイズしたバージョンのOracle Communications Data Modelを本番前、本番の順に展開します。

ヒント:
Oracle Communications Data Modelコンポーネントで提供されるコンポーネントの'クリーンな'コピーを保持します。これは、Oracle Communications Data Modelの新しいバージョンにアップグレードする場合に重要です。

Oracle Communications Data Modelのカスタマイズを開始する前に

Oracle Communications Data Modelのカスタマイズを開始する前に、次のチームおよび委員会が存在することを確認します。

- データ・ウェアハウス管理運営委員会。この運営委員会は、「データ・ウェアハウス管理委員会の責任」に記載されている責任があります。

- 実装チーム。このチームは、「実装者の前提知識」に記載されている専門知識を持つITエンジニアで構成されます。このチームは、「Oracle Communications Data Modelウェアハウスを実装する手順」に記載されている責任があります。

- フィットギャップ分析チーム。このチームは、Oracle Communications Data Modelのビジネス要件および範囲を確認できるビジネス・アナリストおよび実装チームの一部のエンジニアで構成されます。このチームのビジネス・メンバーは、物理モデルの基盤レイヤーおよびアクセス・レイヤーに行う必要がある変更を評価するため、論理データ・モデリングを理解する必要があります。このチームは、「Oracle Communications Data Modelのフィットギャップ分析の実行」に記載されている責任があります。

これらのチームおよび委員会を結成した後:

- アプローチを検討し、カスタマイズに含まれる各パーティの関係および役割を決定します(たとえば、ビジネスおよびITなど)。

- プロジェクトの範囲に合意します(つまり、データ・ウェアハウスに格納する必要がある新しいデータおよびその必要な理由に合意します)。

- タイミングおよび作業の取決めに合意します。

実装者の前提知識

「Oracle Communications Data Modelを構成するOracle製品」で説明したように、Oracle Communications Data ModelはOracleスタックの多くを使用します。したがって、Oracle Communications Data Modelを正常に実装するには、実装チームは次のものが必要です。

- 情報、データ分析およびデータ・モデリングを実行する経験。(Oracle SQL Data Modelerを使用した経験は役立ちます。)

- Oracleテクノロジ・スタック、特にデータ・ウェアハウス(データベース、データ・ウェアハウス、OLAP、データ・マイニング、Warehouse Builder、Oracle Business Intelligence Suite Enterprise Edition)に関する知識。

- 次のものを使用した実践的な経験

- Oracleデータベース

- PL/SQL

- SQL DDLおよびDML構文

- Analytic Workspace Manager

- Oracle SQL Developer

- Oracle Business Intelligence Suite Enterprise Edition Administrator、AnswersおよびDashboards

データ・ウェアハウス管理委員会の責任

管理は、プロセス、規格およびコンプライアンスに関心のある企業の経営チームまたは個人に関係します。データ・ウェアハウスに投資している組織にとっては、さらに重要です。

データ・ウェアハウスの管理は、全体のIT管理のコンテキストで発生します。IT従業員からフロントエンドの業務担当者まで全体の組織で明確に伝える必要がある必須のポリシー、プロセスおよび手順を示します。

Oracle Communications Data Modelをカスタマイズする前に、存在しない場合はデータ・ウェアハウスの管理運営委員会を結成します。この運営委員会の役割は、データ・ウェアハウスを監視し、企業全体に渡って最適なビジネス価値を実現する環境を提供することです。

データ・ウェアハウス管理委員会: 全体の責任

データ・ウェアハウス管理運営委員会は、管理フレームワークの指示および回答を設定し、次の領域を含みます。

- 全体のデータ・ウェアハウスのライフ・サイクル。

- 処理するデータに合意し、エンドユーザーが使用できるようにします。

- エンド・ユーザーが使用可能なデータの最小の品質基準を決定し、データ・ウェアハウスのソース・データであるデータの品質に対するこれらの基準の測定および分析方法を決定します。

- データ・ウェアハウスからコア情報を適用する組織のビジネスの目標。

- データ・リソースおよびデータ・アクセスのポリシー、手順および規格。

- データ・ウェアハウス・コンポーネント管理のライフ・サイクル。

データ・ウェアハウス管理委員会: データ管理責任

データ・ウェアハウス管理の中心は、データ管理です。データ管理タスクは、次のとおりです。

- データ・モデリング規格、メタデータ規格および他の関連規格の承認。これには、「Oracle Communications Data Modelのメタデータの管理」で説明されているメタデータ戦略の決定およびこれらの規格をサポートするデータ・モデリング・ツールの使用の確認が含まれます。

- データ保存ポリシーの決定。

- 法律上の制限およびデータ・セキュリティ・ルールに基づいたデータ・アクセス・ポリシーの設計。

- ビジネス・ユニットの影響分析と一致するデータ・バックアップ戦略の設計。

- データ使用、アクティビティおよびアラートの監視およびレポート。

Oracle Communications Data Modelのメタデータの管理

メタデータはデータに関するデータなので、データ・ウェアハウス環境の重要な側面です。メタデータにより、エンド・ユーザーおよびビジネス・アナリストは、データのコンテキストまたはデータの表現を把握しなくても可能性を調査できます。

メタデータ管理は、企業がデータの構築方法、存在するデータの種類およびデータの意味を確認できる中央環境でメタデータを監視してアクティブに管理する包括的で継続的なプロセスです。変更がデータ・ウェアハウスのすべての場所のデータの整合性に悪影響を与えないよう影響分析を実行するためにOracle Communications Data Modelをカスタマイズする場合の優れたメタデータ管理に特に役立ちます。

- メタデータのカテゴリおよび規格

- メタデータ・リポジトリの操作

- Oracle Communications Data Modelで提供されるメタデータ・リポジトリの参照

- Oracle Communications Data ModelでのOracle Warehouse Builderの使用

メタデータのカテゴリおよび規格

メタデータは、3つの主要なカテゴリに編成されます。

- ビジネス・メタデータは、ビジネス・センスのデータの意味を示します。データ・ウェアハウスのデータ要素のビジネスの解釈は、データベースの実際の表および列の名前に基づいています。このマッピング情報とビジネス定義およびルール情報をビジネス・メタデータに収集します。

- テクニカル・メタデータは、データ型、長さ、系統、データ・プロファイリングの結果などの属性を含むデータの技術的な側面を表します。

- プロセス実行メタデータは、正常にロードされた行、拒否された行、ロード時間などのメジャーを含むETLプロセス自体の実行結果の統計を示します。

メタデータは情報管理で非常に重要なため、多くの組織は次のような様々なレベルでメタデータの標準化を試行しています。

- METS(Metadata Encoding and Transmission Standard)。デジタル・ライブラリ内のオブジェクトに関する記述、管理および構造メタデータをエンコードする規格。

- ANSI(米国規格協会)。米国の自発的な標準化および適合性評価システムを調整する組織。

- ISO(国際標準化機構)。国際交流のための規格を確立、開発および促進する団体。

- コモン・ウェアハウス・メタデータ(CWM)。データ・ウェアハウス環境のリレーショナル、非リレーショナル、多次元および他のほとんどのオブジェクトのメタデータをモデル化するためのOMG(Object Management Group)がリリースおよび所有している仕様。

メタデータ管理ソリューションを実装する場合、データ・ウェアハウス・インフラストラクチャ環境を参照して、準拠する規格を決定してください。

メタデータ・リポジトリの操作

メタデータ・リポジトリを使用して、メタデータを管理します。最上位のレベルで、メタデータ・リポジトリには、3つのレイヤーの情報があります。レイヤーは、次の順序で定義されます。

1. 物理レイヤー。このメタデータ・レイヤーは、ソース・データを識別します。

2. ビジネス・モデルおよびマッピング・レイヤー。このメタデータ・レイヤーは、物理レイヤーを論理カテゴリに編成して、ソース・データにアクセスする適切なメタデータを記録します。

3. プレゼンテーション・レイヤー。このメタデータ・レイヤーは、エンドユーザー・アクセスのビジネス・モデル・エンティティを公開します。

メタデータ・リポジトリを作成する最初の手順は、次の操作でメタデータ管理ニーズを調査することです。

- メタデータ利用者の識別。通常、ビジネス利用者および技術利用者が存在します。

- ビジネスおよび技術メタデータ要件を決定します。

- 特定のデータ要素および論理データ・フローのメタデータ要件の調整。

次に:

- 各部分の重要度を決定します。

- 各部分の担当者の責任を割り当てます。

- 一貫性のある一連の作業メタデータの構成内容を決定します。

- メタデータを格納、バックアップおよびリカバリする場所。

- 各メタデータを必要なユーザーのみが使用できることを確認します。

- メタデータの品質を確認し、メタデータが完全で最新であることを確認します。

- 使用するメタデータ・リポジトリおよび1つの場所からのリポジトリの制御方法の識別。

メタデータ定義を作成した後、メタデータを取得、統合および保守できるデータ・アーキテクチャを確認します。

データがデータ・ウェアハウスで日ごとに変更されるため、メタデータ・リポジトリを更新します。ビジネス・ルール、定義、式またはプロセスを変更する場合(特にOracle Communications Data Modelをカスタマイズする場合)、最初に、メタデータを調査し、影響分析を実行して、提案された変更の影響を受ける可能性があるデータ・ウェアハウス環境のすべての属性を示します。

Oracle Communications Data Modelで提供されるメタデータ・リポジトリの参照

Oracle Communications Data Modelモデルをカスタマイズするには、Oracle Communications Data Modelコンポーネント間の依存性(特にレポートKPIを物理表および列にマップする方法)を理解する必要があります。

Oracle Communications Data Modelは、これらの依存性を検出できる「OCDMメタデータ」ブラウザと呼ばれるツールを用意しています。サンプル・レポートとともにOracle Communications Data Modelをインストールする場合、メタデータ・ブラウザはwebcatのサンプル・ダッシュボードとして提供されます。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

メタデータ・リポジトリを参照するには:

1. ブラウザで、http://servername:9704/analyticsのログイン・ページを開きます。servernameは、webcatがインストールされるサーバーです。

2. ocdmのユーザー名でログインして、パスワードを指定します。

3. メタデータ・ブラウザ・ダッシュボードを選択します。

4. メタデータ・ブラウザのタブを使用して、メタデータを検索します。

- メジャー - エンティティ・タブ

メジャー - エンティティ・タブには、ビジネス・エリア(リレーショナル、OLAP、マイニング)、メジャーの説明、対応する式、担当するエンティティ、およびメジャーの属性が表示されます。

データを参照するには、関心のあるビジネス・エリアとメジャーの説明を選択します。

- エンティティ - メジャー・タブ

エンティティ - メジャータブを使用して、エンティティ、属性、サポートされるメジャーおよびメジャーの計算の間のマッピングを検出できます。特定のエンティティと属性に関する情報も検出できます。

たとえば、次の手順を実行して、エンティティの詳細を学習します。

1. エンティティを選択します。

2. 「移動」をクリックします。

- プログラム - 表タブ

プログラム - 表タブを使用して、Intra-ETLマッピングに関する情報とレポート情報を参照できます。次の手順を実行してください。

1. プログラム・タイプ(つまり、Intra-ETLまたはレポート)およびプログラム名を選択します。

2. 「移動」を選択します。

- 表 - プログラム・タブ

デフォルトで、表 - プログラム・タブに移動する場合、すべてのレポートに使用するすべての表を確認します。

特定の表を使用するレポートを検出するには、右ペインから左(選択済)ペインに特定の表を移動する必要があります。

たとえば、特定の表を使用するレポートを表示するには、次の手順に従います。

1. 表 - プログラム・タブの右ペインで、表を選択します。

2. <(左矢印)をクリックして、左側の「選択済」リストに表を移動します。

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

4. 「移動」を選択します。

選択した表のレポートが表示されます。

Oracle Communications Data ModelでのOracle Warehouse Builderの使用

Oracle Warehouse Builderは、Oracle Communications Data Modelとともに使用できる高度なメタデータ管理機能を用意しています。

ソース・メタデータをOracle Warehouse Builderにインポートする前に、メタデータ定義を含むモジュールを作成します。作成するモジュールのタイプは、メタデータをメタデータ・リポジトリにインポートしているソースに依存します。Oracle Warehouse Builderは、『Oracle Warehouse Builderソースおよびターゲット・ガイド』の説明にあるように、多くの異なるソースおよびターゲットをサポートします。たとえば、Oracle Warehouse BuilderはOracleデータベースに接続すると、表、ビュー、順序、ディメンション、キューブ、データ型、PL/SQLパッケージなど、必要なすべてのメタデータを抽出するためにデータベース・ディクショナリに問い合せます。

Oracle Warehouse Builderでは、Oracle Warehouse Builderリポジトリのメタデータで表されるようにデータ・オブジェクト間の依存性を確認できるメタデータ依存性マネージャと呼ばれるインタフェース・ツールも提供します。メタデータ依存性マネージャでは、インタラクティブな系統および影響ダイアグラムの形式で依存性を表します。系統ダイアグラムではオブジェクトのデータ・フローをソースまで追跡し、それらのパスに沿ってすべてのオブジェクトを表示します。影響ダイアグラムでは選択したオブジェクトから導出されるすべてのオブジェクトを識別します。

メタデータ依存性マネージャで提供される情報により、多くの状況を支援できます。次に例を示します。

1. ディメンション、キューブまたはビジネス・インテリジェンス・ツール・レポートなどのターゲット・オブジェクトから、ターゲットに表示される結果の計算に使用される各データ・ソースの列を識別できます。

2. ソース表、プラッガブル・マッピングなどのプロジェクト全体で使用されるオブジェクトの設計の変更の影響を評価できます。

3. ソース表の列のデータ型への変更など、設計の変更を設計のダウンストリームに伝搬できます。

エンドツーエンド・データ系統および影響分析では、設計変更のプランニングの強化、ソース・システムを変更した場合の予期せぬ影響の識別の迅速化、ビジネス・インテリジェンス結果、マスター・データまたはその他のデータ統合プロセスのより効果的な監査の実現により、プロジェクトのリスクが削減されます。

また、SQLまたはXMLベースのカスタム・メタデータ・ストアを定義および使用して、表やビューなどのソースおよびターゲット・オブジェクトの定義を取得できます。

一部のメインフレーム・ソースから抽出されるデータファイルの場合、Oracle Warehouse Builderを使用してデータファイル構造を示すCOBOLコピーブック・ファイルを解釈し、これに基づくソース・メタデータを作成できます。

Oracle Warehouse Builderアプリケーション・アダプタまたはアプリケーション・コネクタによって、ERPおよびCRMアプリケーション・ソースに関する追加のメタデータが提供されます。

Oracle Warehouse Builderでは、Oracle Enterprise ManagerおよびOracle Workflowに対してのプロセス・フローやスケジュールの配布または実行が可能です。通常、リリース10g以上のどのOracleデータベース・ロケーションにもスケジュールを配布できます。

Oracle Communications Data Modelのフィットギャップ分析の実行

フィットギャップ分析では、情報のニーズと通信ビジネス要件をOracle Communications Data Modelに用意されている構造と比較します。論理モデルおよびデフォルトのスキーマに含まれていないすべての必要な機能および要件を満たすために必要なその他の変更を特定します。

フィットギャップ分析の結果は、カスタマイズ・レポートです。このレポートは、通信環境に合せてOracle Communications Data Modelをカスタマイズするために必要な適応と調整の簡単な説明です。

フィットギャップ分析チームは、次の手順に従って、カスタマイズ・レポートを書き込みます。

1. 以前に評価を実行している場合は、以前のフェーズのドキュメントを確認し、必要に応じて、必要なビジネス専門知識および技術的専門知識を持つチーム・メンバーを追加します。

2. データを確認し、論理エンティティおよびデータ構造とOracle Communications Data Model論理モデルおよびスキーマをマップします。

- ビジネス要件、質問およびルールから開始し、Oracle Communications Data Modelにないエンティティおよび属性を識別します。

- Oracle Communications Data Modelを既存のアプリケーション・モデルと比較します(存在する場合)。

- Oracle Communications Data ModelとOracle Communications Data Modelウェアハウスのデータ・ソースとして使用しているOLTPデータを比較します。

3. ニーズとOracle Communications Data Modelスキーマの差異を識別します。このタスクを支援するため、システムに対して実行される可能性がある作業のリスト(モデルではなく例)を生成し、Oracle Communications Data Modelウェアハウスの機能を評価するためのユースケースを作成します。確認する差異に関して次の質問に答えます。

- 許容できる差異と、調整が必要な差異。

- 許容できない差異について行える処置。

4. カスタマイズしたウェアハウスを作成するため、Oracle Communications Data Modelのデフォルトの設計に対して行う必要がある変更を識別します。次の順序でこれらの変更を識別します。

1. 物理モデル。第2章「物理モデルのカスタマイズ」に記載されているガイドラインに従います。

2. ETLマッピング。第4章「ETLの実装およびカスタマイズ」に記載されているガイドラインに従って、Source-ETLを識別および設計し、Oracle Communications Data Modelで提供されるIntra-ETLを識別および変更します。

ヒント:
変更を識別する場合、変更がセキュリティおよびメタデータ要件を満たしていることを確認します。

5. カスタマイズ・レポートを作成し、Oracle Communications Data Modelをビジネス・ニーズに一致させるために必要な変更を詳細に記述します。これには、既存のシステムのインタフェースの追加および変更が含まれます。

6. カスタマイズ・レポートに基づいて、プロジェクト計画を更新し、「Oracle Communications Data Modelウェアハウスを実装する手順」に記載された手順を実行します。

2 物理モデルのカスタマイズ

この章では、Oracle Communications Data Modelの物理データ・モデルのカスタマイズの一般情報および物理モデルの基盤レイヤーのカスタマイズの詳細情報について説明します。この章の内容は次のとおりです。

- デフォルトの物理モデルの特性

- Oracle Communications Data Model物理モデルのカスタマイズ

- 基盤レイヤーのカスタマイズ

- 物理構造を設計する場合の一般的な推奨事項

関連項目:
第3章「アクセス・レイヤーのカスタマイズ」

デフォルトの物理モデルの特性

Oracle Communications Data Modelのデフォルトの物理モデルの定義は、次のとおりです。

1300個以上の表と11,000個以上の列。

1380個以上の業界固有メジャーおよびKPI

6個の構築済データ・マイニング・モデル

20個の構築済OLAPキューブ

Oracle Communications Data Modelのデフォルトの物理モデルは、「従来のデータ・ウェアハウスのレイヤー」に示されているようにマルチスキーマの従来のデータ・ウェアハウスの特性を共有しますが、「デフォルトのOracle Communications Data Modelウェアハウスのレイヤー」に示されているように単一のスキーマのすべてのデータ構造を定義します。

従来のデータ・ウェアハウスのレイヤー

以前から、データ・ウェアハウス環境に3つのレイヤーが定義されます。

- ステージング・レイヤー。OLTPシステムおよび他のデータ・ソースからデータ・ウェアハウス自体にデータを移動する場合、このレイヤーを使用します。一時的なロード構造および拒否されたデータで構成されます。ステージング・レイヤーを使用すると、ビジネス・ユーザーに影響を与えることなくオペレーティング・システムからデータ・ウェアハウスへのデータの迅速な抽出、変換およびロード(ETL)を実行できます。このレイヤーで、ほとんどの複雑なデータ変換およびデータ品質処理が発生します。ステージング・レイヤーの設計の最も基本的なアプローチは、ソース・オペレーティング・システムに存在するスキーマと同じスキーマを使用することです。

注意:
基盤レイヤーに直接挿入される前にデータがソース・システムから抽出され、すべてのデータ変換処理が即座に実行されるため、一部の実装でこのレイヤーは必要ありません。

- 基盤レイヤーまたは統合レイヤー。このレイヤーは、以前から第3正規形(3NF)スキーマとして実装されています。3NFスキーマは、アプリケーションとは独立した中立的なスキーマ設計で、通常多数の表があります。データの冗長性なしで各トランザクションの詳細なレコードを保存し、属性およびデータ要素間のすべてのリレーションシップの豊富なエンコーディングを使用できます。通常、ユーザーは、データを確実に理解して、詳細な構造を確実に操作する必要があります。このレイヤーでは、データの具体化が開始されますが、アクセスおよびパフォーマンス・レイヤーに変換される前にデータが使用可能になるので、特に時間に依存する場合にエンドユーザー・アプリケーションでこのレイヤーのデータにアクセスすることは珍しくありません。

- アクセス・レイヤー。このレイヤーは、データのフラット化されたビューまたは次元ビューを示すスノーフレークまたはスター・スキーマとして以前から定義されています。

デフォルトのOracle Communications Data Modelウェアハウスのレイヤー

Oracle Communications Data Modelウェアハウス環境も3つのレイヤーで構成されますが、図2-1「Oracle Communications Data Modelウェアハウスのレイヤー」の点線で示されているように、Oracle Communications Data Modelで、基盤レイヤーおよびアクセス・レイヤーの定義は単一のスキーマに結合されます。

図2-1 Oracle Communications Data Modelウェアハウスのレイヤー

「図2-1 Oracle Communications Data Modelウェアハウスのレイヤー」の説明

Oracle Communications Data Modelウェアハウスのレイヤーは、次のとおりです。

- ステージング・レイヤー。従来のデータ・ウェアハウス環境のように、Oracle Communications Data Modelウェアハウス環境でステージング・レイヤーを使用できます。このレイヤーの定義は顧客ごとに異なるため、この領域の定義はOracle Communications Data Modelの一部として提供されません。

注意:
Oracle Communications Data Modelのアプリケーション・アダプタを使用してOracle Communications Data Modelの基盤レイヤーを移入する場合、アダプタがOracle Communications Data Modelステージング・レイヤーを定義および移入します。

- 基盤レイヤーおよびアクセス・レイヤー。これらのレイヤーの物理オブジェクトは、単一のスキーマのocdm_sysスキーマに定義されます。

- 基盤レイヤー。Oracle Communications Data Modelの基盤レイヤーは、3NF(つまり、DWB_接頭辞を持つ表)でデータを表示する実表で定義されます。このレイヤーには、ocdm_sysスキーマ(つまり、DWR_、DWL_、DWC_接頭辞を持つ表)で定義される参照表、検索表および制御表も含まれます。

- アクセス・レイヤー。Oracle Communications Data Modelのアクセス・レイヤーは、導出表および集計表(DWD_およびDWA_接頭辞を使用して定義されます)、キューブ(CB$接頭辞を使用して定義されます)およびビュー(_VIEW接尾辞を使用して定義されるビュー)で定義されます。これらの構造は、基盤レイヤーのデータの要約またはフラット化された視点を示します。
このレイヤーは、導出表(DWD_)に格納されるデータ・マイニング・モデルの結果も含みます。モデル自体は、ocdm_miningスキーマに定義されます。

参照:
ocdm_sysスキーマの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

Oracle Communications Data Model物理モデルのカスタマイズ

Oracle Communications Data Model物理データ・モデルの開始点は、3NF論理データ・モデルです。物理データ・モデルは、論理モデルをできるだけミラー化し、(ただし、表または列の構造の変更が必要になる場合があります)データベース・オブジェクト(表、キューブ、ビューなど)を定義します。

Oracle Communications Data Modelのデフォルトの物理モデルをカスタマイズするには、次の手順に従います。

1. 「物理モデルをカスタマイズする前に答える質問」に記載されている質問に答えます。

2. 「デフォルトの物理モデルの特性」に記載され、詳細が『Oracle Communications Data Modelリファレンス』に示されているOracle Communications Data Modelの論理および物理モデルの特性についてよく理解します。

3. 必要に応じて、Oracle Communications Data Modelの物理モデルのFoundationレベルを変更します。カスタマイズが必要な場合の説明は、「一般的な変更シナリオ」を参照してください。
物理構造を定義する場合:

- 3NF形式の基盤レイヤーを保持します。

- 「物理構造を設計する場合の一般的な推奨事項」の情報を使用して、物理オブジェクトを設計する場合を説明します。

- 「物理モデルをカスタマイズする場合の規則」に記載されているOracle Communications Data Modelのデフォルトの物理モデルを作成する場合に使用する規則に従います。

ヒント:
ocdm_sysスキーマへのパッチとして物理データ・モデルに行う変更をパッケージ化します。

4. 第3章「アクセス・レイヤーのカスタマイズ」の説明に従って、Oracle Communications Data Modelの物理モデルのアクセス・レイヤーを変更します。

物理モデルをカスタマイズする前に答える質問

物理モデルを設計する場合、論理データ・モデルが物理データ・モデルと1対1ではないことに注意してください。論理データ・モデルを物理レイヤーに変換する場合、ロード、問合せおよびメンテナンス要件を検討します。たとえば、物理データ・モデルを設計する前に、次の質問に答えます。

- 論理データ・モデルの全範囲または範囲の一部のみを含む物理データ・モデルが必要ですか。
「一般的な変更シナリオ」では、ビジネス・ニーズがOracle Communications Data Model論理モデルと同じ論理モデルにならない場合の物理データ・モデルの変更の概要を説明します。

- ソース・データ・プロファイルの結果は何ですか。

- 各表のデータ・ロード頻度は何ですか。

- どれだけ大きい表がありますか、それはどの表ですか。

- どうすれば表と列にアクセスできますか。共通結合は何ですか。

- データ・バックアップ戦略は何ですか。

物理モデルをカスタマイズする場合の規則

Oracle Communications Data Modelの物理モデルを開発する場合、次に示すような規則に従いました。物理モデルをカスタマイズする場合、継続してこれらの規則に従います。

物理オブジェクトの一般的なネーミング規則

定義する物理オブジェクトの名前を付けるには、次のガイドラインに従います。

- 物理オブジェクトの名前を付ける場合、Oracle Databaseスキーマ内のオブジェクトの名前を付けるネーミング・ガイドラインに従います。次に例を示します。

- 表および列の名前は文字で始める必要があり、30文字以下の英数字のみで使用できます。スペースや"!"などの一部の特殊文字および予約語は使用できません。

- 表名は、ビューおよびシノニムで共有するスキーマ内で一意である必要があります。

- 列名は、表内で一意である必要があります。

- 物理モデリング・ステージで略称を使用することが一般的ですが、論理モデルのエンティティ名に対応する物理オブジェクトの名前をできるだけ使用します。プログラマおよびユーザーの混乱を避けるため、一貫性のある略称を使用します。

- 列の名前を付ける場合、可能であればショート名を使用します。列のショート名は、SQLコマンド解析に必要な時間を削減します。

- Oracle Communications Data Modelで提供されるocdm_sysスキーマは、次の表に示されている接頭辞および接尾辞を使用して、オブジェクト・タイプを識別します。

プリフィクスまたはサフィックス

次のオブジェクトの名前に使用

CB$

OLAPキューブのマテリアライズド・ビュー。このマテリアライズド・ビューは、OLAPサーバーによって自動的に作成されます。
注意: このオブジェクトのレポートまたは問合せを実行しないでください。かわりに、対応する_VIEWオブジェクトにアクセスします。

DMV_

パフォーマンスのために作成された(つまり、集計表やOLAPキューブではない)マテリアライズド・ビュー。

DWA_

マテリアライズド・ビューの集計表。

DWB_

ベース・トランザクション・データ(3NF)表。

DWC_

制御表。

DWD_

導出表 -- データ・マイニング結果表を含む。

DWL_

検索表。

DWV_

時間ディメンションのリレーショナル・ビュー

DWR_

参照データ表。

_VIEW

OLAPキューブ、ディメンションまたは階層のリレーショナル・ビュー。

定義する新しい表、ビューおよびキューブに対して、これらの接頭辞および接尾辞を使用します。

参照:
デフォルトのOracle Communications Data Modelのオブジェクトの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

ドメイン定義規格

ドメインは、列に使用できる一連の値です。データベースに加えて外部キー、チェック制約またはアプリケーションでドメインを適用できます。モデル間の各ドメインの次のような規格を定義します。

- 'YYYY-MM-DD'などの日時タイプ。

- 様々な状況の数値。

- 様々な状況の文字列の長さ。

- キーや説明などのコード値定義。

基盤レイヤーのカスタマイズ

Oracle Communications Data Modelの物理モデルのカスタマイズの最初の手順は、物理データ・モデルの基盤レイヤーのカスタマイズです。「デフォルトのOracle Communications Data Modelウェアハウスのレイヤー」で示されているように、物理モデルの基盤レイヤーはOracle Communications Data Modelの3NF論理モデルをミラー化するので、論理モデル・ニーズとOracle Communications Data Modelのデフォルトの論理モデルの違いを反映するため、基盤レイヤーのカスタマイズを選択できます。また、パフォーマンスを向上するには、基盤レイヤーの物理オブジェクトのカスタマイズが必要な場合があります(たとえば、一部の基盤レイヤー表の圧縮を選択する場合があります)。

基盤レイヤーに変更を加える場合、次の点に注意してください。

- 基盤レイヤー・オブジェクトを変更して論理モデル設計を反映する場合、できるだけ変更は少なくします。「一般的な変更シナリオ」は、このような最も一般的なカスタマイズの変更を示しています。

- 新しい基盤レイヤーを定義する場合またはパフォーマンスの向上のために既存の基盤レイヤー・オブジェクトを再設計する場合、「物理構造を設計する場合の一般的な推奨事項」および「物理モデルをカスタマイズする場合の規則」に従います。

- 基盤レイヤー・オブジェクトの変更は、アクセス・レイヤー・オブジェクトにも影響する場合があります。

注意:
Oracle Communications Data Modelを慎重に変更してください。Oracle Communications Data Modelの物理モデルの基盤レイヤーは、柔軟性および拡張性を実現する一連の汎用構造が中心にあります。広範囲の追加、削除または変更を行う前に、Oracle Communications Data Modelのすべての機能を理解し、基盤レイヤーのデフォルトのオブジェクトを使用して要件を処理できないことを確認します。

一般的な変更シナリオ

物理データ・モデルの基盤レイヤーをカスタマイズする場合、複数の一般的な変更シナリオがあります。

- 既存の構造への追加
Oracle Communications Data Modelの物理データ・モデルのデフォルトの基盤レイヤーでサポートされていないビジネス・エリアまたはプロセスを確認する場合、新しい表および列を追加します。

追加を行う場合の冗長構造の作成を回避するには、Oracle Communications Data Modelの物理データ・モデルのデフォルトの基盤レイヤー(および基礎となる論理データ・モデル)を慎重に調査します。これらの追加でビジネス価値に高い付加価値が得られる場合、今後リリースされるOracle Communications Data Modelへの追加を検討するため、Oracle Communications Data Model開発チームに追加内容を通知します。

- 既存の構造の削除
レガシー・システムのビジネス要件と一致しないモデルの領域がある場合、これらの構造を保持してウェアハウスの該当する部分を移入しない方が安全です。

物理データ・モデルの基盤レイヤーの表を削除すると、モデルの他の部分に必要なリレーションシップまたはそれに基づくアプリケーションを破棄できます。初期実装中に一部の表が不要な場合がありますが、これらの構造を後で使用する可能性があります。この可能性がある場合、ここで構造を保持すると後の作業が少なくなります。表を削除する場合、完全な分析を実行してエンティティからのすべてのリレーションシップを確認します。

- 既存の構造への変更
状況によって、Oracle Communications Data Modelの物理データ・モデルの基盤レイヤーの一部の構造は、使用される対応する構造と完全に一致しない場合があります。変更を実装する前に、変更によるOracle Communications Data Modelのデータベース設計への影響を確認します。また、新しい設計に基づいたアプリケーションの影響を確認します。

物理構造を設計する場合の一般的な推奨事項

データ・アクセスおよびパフォーマンスのベスト・プラクティスに従って、Oracle Communications Data Modelで提供されるocdm_sysスキーマが設計および定義されました。新しい物理オブジェクトを追加する場合、これらのプラクティスを引き続き使用します。この項では、次の物理設計の側面の決定がデフォルトのOracle Communications Data Modelに行われた方法について説明します。

- Oracle Communications Data Modelの表領域

- Oracle Communications Data Modelのデータ圧縮

- Oracle Communications Data Modelのスーパータイプおよびサブタイプ・エンティティの表

- 物理モデルのサロゲート・キー

- Oracle Communications Data Modelの整合性制約

- Oracle Communications Data Modelの索引とパーティション索引

- Oracle Communications Data Modelのパーティション表

- Oracle Communications Data Modelのパラレル実行

Oracle Communications Data Modelの表領域

表領域は、使用中のオペレーティング・システム内の物理構造である1つ以上のデータファイルで構成されます。

推奨: 表領域の定義

可能であれば、論理的なビジネス・ユニットを表すため、表領域を定義します。

非常に大きいOracle Communications Data Modelウェアハウスを大幅に改善するには、非常に大きいデータ・ファイルを使用します。

表で使用される表領域とパーティションの変更

Oracle Communications Data Model表で使用する表領域およびパーティションを変更できます。行う作業は、Oracle Communications Data Model表にパーティションがあるかどうかによって決まります。

- パーティションのない表(つまり、検索表および参照表)の場合、表の既存の表領域を変更できます。
デフォルトでは、Oracle Communications Data Modelはパーティション表を時間隔パーティションとして定義します。これは、新規データが到着したときのみパーティションが作成されることを意味します。

したがって、パーティションのあるOracle Communications Data Model表(つまり、実表、導出表および集計表)で、現在の表領域ではなく新しい表領域に新しい時間隔パーティションを生成する場合は、次の文を発行します。

ALTER TABLE table_name MODIFY DEFAULT ATTRIBUTES
TABLESPACE new_tablespace_name;

table_nameで指定された表に新規データが挿入されると、tablespace new_tablespace_nameで指定された表領域に新しいパーティションが自動的に作成されます。

- パーティションのある表(つまり、実表、導出表および集計表)の場合は、新しい表領域に新しい時間隔パーティションが生成されることを指定できます。
パーティションのないOracle Communications Data Model表(つまり、検索表と参照表)で、表の既存の表領域を変更するには、次の文を発行します。

ALTER TABLE table_name MOVE TABLESPACE new_tablespace_name;

Oracle Communications Data Modelのデータ圧縮

実行する必要がある主な決定は、データを圧縮するかどうかです。表の圧縮を使用すると、ディスクおよびメモリーの使用率が削減され、多くの場合に読取り専用操作のスケールアップ・パフォーマンスが向上します。また、表の圧縮は、ディスクのデータの取得に必要なラウンド・トリップの数を最小化して、問合せ実行を高速化できます。ただし、データの圧縮は、データのロード速度でパフォーマンスが低下します。

推奨: データの圧縮

通常、データの圧縮を選択します。通常、全体のパフォーマンスの改善は、圧縮のコストを上回ります。

圧縮を使用する場合、ロードして最適な圧縮率を達成する前に、データのソートを検討してください。受信データをソートする最も簡単な方法は、CTASまたはIAS文にORDER BY句を使用してロードします。多数の異なる値(1,000から10,000)を含むNOT NULL列(数値以外を推奨)のORDER BYを指定します。

関連項目:
「使用できるデータ圧縮のタイプ」および「マテリアライズド・ビューの圧縮」

使用できるデータ圧縮のタイプ

Oracle Databaseは、次のタイプの圧縮を提供します。

- 基本または標準の圧縮

- OLTP圧縮

- Hybrid Columnar圧縮(HCC)

基本または標準の圧縮

標準の圧縮を使用する場合、Oracle Databaseは、データベース・ブロックの重複値を削除して、データを圧縮します。標準の圧縮は、ダイレクト・パス操作(CTASまたはIAS)にのみ有効です。あらゆる従来のDML操作(更新など)を使用してデータを変更する場合、変更を行うためにデータベース・ブロック内のデータの圧縮が解除され、圧縮されないでディスクに書き込まれます。

特にリレーショナル・データに設計された圧縮アルゴリズムを使用すると、圧縮表にアクセスするSQL問合せのパフォーマンスの低下がほとんど発生しない方法で、Oracle Databaseはデータを効果的に圧縮します。

Oracle Communications Data Modelは、すべての実表、導出表および集計表に圧縮機能を利用します。これにより、格納されるデータ量とメモリー使用率が削減され(メモリー・ブロック当たりのデータが増えます)、問合せのパフォーマンスが向上します。

CREATE TABLE文のCOMPRESS句を使用して表の圧縮を指定するか、次に示すようにALTER TABLE文を使用して既存の表に対して圧縮を有効にできます。

alter table <tablename> move compress;

例2-1 Oracle Communications Data Modelの圧縮表の作成

DWB_ACCS_MTHD_PORT_HISTという圧縮表を作成するには、次の手順を実行します。

COMPRESS
Create table DWB_ACCS_MTHD_PORT_HIST
(NP_RQST_HDR_CD                 VARCHAR2(30)
,ACCS_MTHD_KEY                   NUMBER(30)  NOT NULL ENABLE
,EXTRNL_OPRTR_KEY                NUMBER(30)
…..
)
tablespace TBS_BASE
COMPRESS ;

OLTP圧縮

OLTP圧縮は、拡張圧縮オプションのコンポーネントです。OLTP圧縮を使用する場合、標準の圧縮と同じように、Oracle Databaseは、データベース・ブロックの重複値を削除して、データを圧縮します。ただし、標準の圧縮と異なり、OLTP圧縮は、INSERTおよびUPDATEなどの従来のDMLを含むすべてのタイプのデータ操作中にデータの圧縮を維持できます。

参照:
OLTP表の圧縮機能の詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle By Example:
Oracle Advanced Compressionの詳細は、ストレージ・コストを節約する表圧縮の使用に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

Hybrid Columnar圧縮(HCC)

HCCはストレージ形式で使用可能で、一連のHybrid Columnar圧縮行の格納に使用される圧縮ユニットと呼ばれる論理構成を使用して圧縮を実現します。データがロードされると、一連の行が列の表現にピボットされて圧縮されます。行のセットの列データが圧縮されると、圧縮ユニットに格納されます。従来のDMLがHCCを使用した表に発行されると、変更を行うために必要なデータの圧縮が解除され、ブロックレベルの圧縮アルゴリズムを使用してデータがディスクに書き込まれます。

ヒント:
データ・セットが従来のDMLを使用して頻繁に変更される場合、HCCの使用は推奨しません。かわりに、OLTP圧縮の使用をお薦めします。

HCCは、問合せパフォーマンスまたは圧縮率に焦点を当てた様々なレベルの圧縮を提供します。問合せ用に最適化されたHCCを使用すると、少ない圧縮アルゴリズムがデータに適用され、パフォーマンスに影響をほとんど与えないで適切な圧縮を実現します。ただし、アーカイブ用の圧縮は、問合せパフォーマンスの潜在的な影響に関係なく、ディスクの圧縮の最適化を試行します。

関連項目:
HCCの説明は、『Oracle Database概要ガイド』を参照してください。

Oracle Communications Data Modelのスーパータイプおよびサブタイプ・エンティティの表

スーパータイプは、1つ以上のサブタイプのリレーションシップを持つ汎用エンティティ・タイプです。

サブタイプは、組織にとってわかりやすく、他のサブグループと区別して一般的な属性またはリレーションシップを共有するエンティティ・タイプのエンティティのサブグループです。

- サブタイプは、すべてのスーパータイプ属性を継承します。

- サブタイプには、他のサブタイプと異なる属性があります。

推奨: スーパータイプおよびサブタイプ・エンティティの表

次の理由のため、スーパータイプおよびすべてのサブタイプのエンティティの個別の表を作成します。

- データベース・レベルで適用されるデータ整合性(NOT NULL列制約の使用)

- リレーションシップを正確にモデル化して適用できます(1つのサブタイプのみに適用されるリレーションシップを含む)。

- 物理モデルは、論理データ・モデルと非常に似ています。

- 論理データ・モデルと物理データ・モデルを関係付けて、論理データ・モデルの拡張機能と変更をサポートすることが容易になります。

- 物理データ・モデルは、実際のビジネス・ルールを反映します(たとえば、1つのサブタイプのみに必要な属性またはリレーションシップが存在する場合など)。

物理モデルのサロゲート・キー

主キーの作成のサロゲート・キー方法には、ソース・システムから自然キー・コンポーネントを取得し、一意のキー値を自然キー・コンポーネントの一意の各組合せに割り当てるプロセス(ソース・システム識別子を含む)でマップすることが含まれます。作成される主キー値は完全に非インテリジェントで、通常最大パフォーマンスおよびストレージ効率性のための数値のデータ型です。

サロゲート・キーのメリットは次のとおりです。

- 一意性の確認: データ分散

- ソース・システムの独立

- 番号変更処理

- 重複する範囲

- 主キーおよび結合の最もパフォーマンスが高いデータ型の数値のデータ型の使用

サロゲート・キーのデメリットは次のとおりです。

- ETL中の割当てが必要

- 再処理およびデータ品質修正が複雑で高負荷

- パフォーマンスに影響するため、問合せでは使用不可

- 業務系ビジネス・インテリジェンスには、業務系システムに結合するための自然キーが必要

Oracle Communications Data Modelの整合性制約

整合性制約は、データベースに関連したビジネス・ルールを規定し、表中の無効な情報を防止するために使用されます。最も一般的なタイプの制約は、次のとおりです。

- 通常サロゲート・キー列で定義され、レコード識別子の一意性を確認するPRIMARY KEY制約。通常、ENFORCED ENABLED RELYモードを指定することをお薦めします。

- 特定の列(または列のセット)が一意であることを確認するUNIQUE制約。緩やかに変化するディメンションの場合、ビジネス・キーおよび有効期間開始日の列の一意制約を追加して、同じビジネス・キー・レコードの複数のバージョン(サロゲート・キーに基づく)の追跡を許可することをお薦めします。

- NULL値が許可されないことを確認するNOT NULL制約。クエリー・リライト・シナリオの場合、主キー制約の他に主キー列のインラインの明示的なNOT NULL制約を使用することをお薦めします。

- 表間の関係がデータで参照されることを確認するFOREIGN KEY制約。通常データ・ウェアハウス環境で、外部キー制約はRELY DISABLE NOVALIDATEノードにあります。

Oracle Databaseでは、SQL問合せを最適化するときに、制約が使用されます。制約は、問合せの最適化に多くの点で効果的ですが、マテリアライズド・ビューのクエリー・リライトに特に重要です。ある特定の状況では、制約はデータベースの領域を必要とします。このような制約は、基礎となる一意索引の形式になっています。

多くのリレーショナル・データベース環境とは異なり、データ・ウェアハウスのデータは通常、抽出、変換、ロード(ETL)プロセス中の、制御された状況下で追加または変更されます。

Oracle Communications Data Modelの索引とパーティション索引

索引は、表またはクラスタに関連付けられたオプションの構造体です。データ・ウェアハウス環境では、従来のBツリー索引に加えて、ビットマップ索引がきわめて一般的です。

- ビットマップ索引は、セット指向の操作に最適化された索引構造です。また、スター型変換など、最適化された一部のデータ・アクセス方法にも必要になります。通常、ビットマップ索引のサイズは、表内の索引付けされたデータの何分の1かの大きさで済みます。

- Bツリー索引は、カーディナリティが高いデータ(customer_nameやphone_numberなど、固有な値を多く持つデータ)に対して最も効果的です。ただし、大規模な表を従来のBツリー索引で完全に索引付けすると、索引が、表にあるデータの数倍の大きさになる場合があるため、ディスク領域の点で非常にコストが高くなります。Bツリー索引は、明示的に圧縮して格納することで、領域を大幅に節約することが可能です。この際、各索引ブロックにはより多くのキーが格納され、I/Oの削減およびパフォーマンスの向上にもつながります。

推奨: 索引とパーティション索引

カスタマイズされたOracle Communications Data Modelビットマップ索引でほとんどの索引を作成します。

一意の列またはカーディナリティが非常に高い他の列(つまり、ほとんどの一意である列)にのみ、Bツリー索引を使用します。Bツリー索引は圧縮して格納します。

索引をパーティション化します。索引は、パーティション化できるという点では表と同じですが、パーティション化方法は表の構造に依存しません。索引をパーティション化すると、リフレッシュ時にデータ・ウェアハウスを管理しやすくなり、問合せのパフォーマンスが改善されます。

通常、ローカルとしてパーティション表の索引を指定します。パーティション表のビットマップ索引は、常にローカルである必要があります。パーティション表のBツリー索引は、ローカルまたはグローバルにできます。ただし、データ・ウェアハウス環境で、ローカル索引はグローバル索引よりも一般的です。ローカル索引では満たせない特定の要件(非パーティション化キーの一意索引や、パフォーマンス要件など)がある場合のみ、グローバル索引を使用します。

関連項目:
「Oracle Communications Data Modelのパーティション表」、「マテリアライズド・ビューの索引の選択」、「Oracle Communications Data Modelのキューブ・パーティション化戦略の選択」および「パーティション化とマテリアライズド・ビュー」

Oracle Communications Data Modelのパーティション表

パーティション化により、表、索引および索引構成表をより細かい単位に細分化できるようになります。データベース・オブジェクトの単位をパーティションと呼びます。各パーティションには独自の名前があり、独自の記憶特性を持つことができます。データベース管理者の視点からすると、パーティション・オブジェクトには、まとめて管理することも個別に管理することも可能な複数の単位があります。このため、管理者は、パーティション・オブジェクトをかなり柔軟に管理できます。ただし、アプリケーションの視点から、パーティション表は非パーティション表と同じです。SQL DMLコマンドを使用してパーティション表にアクセスする場合、変更は必要ありません。

次のトピックで説明するように、パーティション化によって、管理性、可用性およびパフォーマンスが向上し、多様なアプリケーションに大きなメリットがもたらされます。

- 管理性のためのOracle Communications Data Modelのパーティション化

- 簡単なデータ・アクセスのためのOracle Communications Data Modelのパーティション化

- 結合パフォーマンスのためのOracle Communications Data Modelのパーティション化

Oracle By Example:
Oracle Databaseの様々なパーティション化技術を理解するには、Oracle Database 11gのパーティションの操作に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

関連項目:
「Oracle Communications Data Modelの索引およびパーティション索引」、「Oracle Communications Data Modelのキューブ・パーティション化戦略の選択」および「パーティション化とマテリアライズド・ビュー」

管理性のためのOracle Communications Data Modelのパーティション化

レンジ・パーティション化により、大量のデータの管理性および可用性を向上できます。

2年分の売上データまたは100TBが表に格納されている事例を検討します。1日の最後に、新しいバッチのデータを表にロードして、最も古い日のデータを削除する必要があります。Sales表を日単位でレンジ・パーティション化する場合、パーティション交換ロードを使用して、新しいデータをロードできます。これは、エンド・ユーザー問合せにほとんど影響しない1秒以内の操作です。

簡単なデータ・アクセスのためのOracle Communications Data Modelのパーティション化

また、レンジ・パーティション化により、問合せに応答するための必要なデータのみスキャンすることを確認できます。ビジネス・ユーザーが週単位(たとえば、週ごとの売上合計など)で売上データに主にアクセスすると想定する場合、日単位でこの表をレンジ・パーティション化すると、全体の表ではなく7つのパーティションのみをスキャンしてビジネス・ユーザーの問合せに応答するため、データに最も効率的な方法でアクセスできます。関係ないパーティションのスキャンを回避する機能は、パーティション・プルーニングと呼ばれます。

結合パフォーマンスのためのOracle Communications Data Modelのパーティション化

パフォーマンスのため、ハッシュによるサブパーティション化を主に使用します。Oracle Databaseは、線形ハッシング・アルゴリズムを使用して、サブパーティションを作成します。

ハッシュ・パーティション化の主なパフォーマンスの利点は、パーティション・ワイズ結合です。パーティション・ワイズ結合では、結合がパラレルで実行されるときにパラレル実行サーバー間で交換されるデータ量が最小限に抑えられ、問合せのレスポンス時間が短縮されます。レスポンス時間は大幅に短縮され、CPUとメモリー・リソースの使用率が改善されます。クラスタ化されたデータ・ウェアハウスで、大規模な結合操作で優れたスケーラビリティを実現するために重要なインターコネクト(IPC)でのデータ・トラフィックを制限して、レスポンス時間が大幅に短縮されます。パーティション・ワイズ結合は、結合する表のパーティション・スキームによってフルまたはパーシャルになります。

図2-2に、フル・パーティション・ワイズ結合が2つの大きい表の結合を複数の小さい結合に分割する方法を示します。小さい各結合は、結合される表ごとに、パーティションのペアの結合を実行します。フル・パーティション・ワイズ結合方法を選択するオプティマイザには、両方の表を結合キーでパーティション化する必要があります。つまり、同じパーティション化方法を使用した同じ列でパーティション化する必要があります。フル・パーティション・ワイズ結合のパラレル実行はシリアル実行と似ていますが、一度に1つのパーティション・ペアを結合するかわりに複数のパーティション・ペアを複数のパラレル問合せサーバーで結合する点が異なります。パラレルで結合するパーティションの数は、並列度(DOP)によって決定されます。

図2-2 結合パフォーマンスのパーティション化

「図2-2 結合パフォーマンスのパーティション化」の説明

推奨: ハッシュ・パーティションの数

ハッシュ・パーティション間でデータを確実に均等に分散するには、ハッシュ・パーティションの数を2の累乗(たとえば、2、4、8など)にすることを強くお薦めします。表に使用するハッシュ・パーティションの数を決定する場合に従う優れた経験則として、2 X # CPUs(2の累乗まで丸める)があります。

システムに12個のCPUがある場合、ハッシュ・パーティションに適切な数は32です。クラスタ化されたシステムで、同じルールが適用されます。それぞれに4個のCPUを使用した3つのノードがある場合、ハッシュ・パーティションの適切な数は32です。ただし、各ハッシュ・パーティションのサイズが少なくとも16MBであることを確認してください。多くの小さいパーティションは、パラレル問合せで効率的なスキャン率ではありません。したがって、CPU数の使用でハッシュ・パーティションのサイズが小さくなりすぎる場合、かわりに環境のOracle RACノードの数(2の累乗まで丸めます)を使用します。

Oracle Communications Data Modelのパラレル実行

パラレル実行により、データベース・タスクをパラレル化または小さい作業単位に分割できるため、複数のプロセスを同時に実行できます。パラレル化を使用すると、TB単位のデータを時間単位や日単位ではなく、数分以内でスキャンして処理できます。

図2-3に、SalesおよびCustomersの2つの表間のフル・パーティション・ワイズ結合のパラレル実行を示します。両方の表の並列度およびパーティション数は同じです。日付フィールドでレンジ・パーティション化され、cust_idフィールドでハッシュを使用してサブパーティション化されます。図に示すように、各パーティション・ペアがデータベースから読み取られ、直接結合されます。

データの再分散が必要ないため、特にノード間でIPC通信を最小化します。次の図に、この結合を確認する実行計画を示します。

図2-3 2つの表間のフル・パーティション・ワイズ結合のパラレル実行

「図2-3 2つの表間のフル・パーティション・ワイズ結合のパラレル実行」の説明

パラレルでパーティション・ワイズ結合を実行する場合に最適なパフォーマンスを取得するには、結合に使用する並列度よりも大きい各表のパーティションの数を指定します。パラレル・サーバーよりも多くのパーティションがある場合、各パラレル・サーバーに結合するパーティションの1つのペアが提供され、パラレル・サーバーが結合を完了すると、結合する別のペアのパーティションがリクエストされます。すべてのペアが処理されるまで、このプロセスが繰り返されます。この方法により、動的にロード・バランスできます(たとえば、並列度32の128個のパーティションなど)。

結合している1つの表のみをパーティション化するとどうなるのでしょうか。この場合、オプティマイザはパーシャル・パーティション・ワイズ結合を選択できます。フル・パーティション・ワイズ結合とは異なり、1つの表のみが結合キーでパーティション化されている場合にパーシャル・パーティション・ワイズ結合を適用できます。したがって、パーシャル・パーティション・ワイズ結合は、フル・パーティション・ワイズ結合よりも一般的です。パーシャル・パーティション・ワイズ結合を実行するために、Oracle Databaseによって、パーティション表のパーティション化戦略に基づいて、もう一方の表が動的に再パーティション化されます。

もう一方の表が再パーティション化された後は、フル・パーティション・ワイズ結合と同様に実行されます。再分散操作には、パラレル実行サーバー間での行の交換が伴います。データをノード境界で再パーティション化する必要があるため、この操作は、Oracle RAC環境のインターコネクト・トラフィックにつながります。

図2-4に、パーシャル・パーティション・ワイズ結合を示します。図2-3と同じ例を使用しますが、顧客表がパーティション化されない点が異なります。結合操作を実行する前に、顧客表の行が結合キーで動的に再分散されます。

図2-4 パーシャル・パーティション・ワイズ結合

「図2-4 パーシャル・パーティション・ワイズ結合」の説明

セッションのパラレル実行の有効化

パラレル問合せは、Oracle Databaseの最もよく使用されているパラレル実行機能です。パラレル実行により、大きな問合せの経過時間を大幅に短縮できます。セッション全体のパラレル化を有効にするには、次の文を実行します。

alter session enable parallel query;

DML操作のパラレル実行の有効化

INSERT、UPDATE、DELETEなどのデータ操作言語(DML)操作は、Oracle Databaseでパラレル化できます。パラレル実行により大きなDML操作を高速化でき、データ・ウェアハウス環境ではパラレル実行が特に有効です。DML文のパラレル化を有効にするには、次の文を実行します。

alter session enable parallel dml;

INSERT、UPDATE、DELETEなどのDML文を発行すると、Oracle Databaseは一連のルールを適用してその文をパラレル化できるかどうかを判断します。ルールは、文がDML INSERT文であるか、DML UPDATEまたはDELETE文であるかによって異なります。

- 次のルールは、DML UPDATEおよびDELETE文のパラレル化の方法を決定するときに適用されます。

- Oracle Databaseはパーティション表に対するUPDATEおよびDELETE文をパラレル化できますが、パラレル化できるのは複数パーティションが関係する場合だけです。

- パーティション化されていない表に対して、または操作が単一パーティションにのみ影響する場合は、UPDATEまたはDELETE操作をパラレル化できません。

- 次のルールは、DML INSERT文のパラレル化の方法を決定するときに適用されます。

- VALUES句を使用する標準INSERTはパラレル化できません。

- Oracle Databaseは、INSERT . . . SELECT . . . FROM文のみパラレル化できます。

表レベルでのパラレル実行の有効化

表のパラレル化の設定は、オプティマイザに影響します。したがって、パラレル問合せを使用する場合は、次の文を発行して表レベルでのパラレル化も有効にします。

alter table <table_name> parallel 32;

3 アクセス・レイヤーのカスタマイズ

この章では、Oracle Communications Data Modelのアクセス・レイヤーのカスタマイズについて説明します。内容は次のとおりです。

- Oracle Communications Data Modelのアクセス・レイヤーのカスタマイズの概要

- Oracle Communications Data Modelの導出表

- Oracle Communications Data Modelの集計表

- Oracle Communications Data Modelの次元コンポーネント

- Oracle Communications Data Modelのマテリアライズド・ビュー

関連項目:
第2章「物理モデルのカスタマイズ」

Oracle Communications Data Modelのアクセス・レイヤーのカスタマイズの概要

Oracle Communications Data Modelのアクセス・レイヤーは、ビジネス・インテリジェンス・ツールに必要なデータの計算および要約(「フラット化」)の視点を提供します。基盤レイヤーの3NFオブジェクトのデータを使用して、アクセス・レイヤー・オブジェクトが移入されます。

ocdm_sysスキーマのアクセス・レイヤー・オブジェクトには、導出表および集計表、OLAPキューブおよびマテリアライズド・ビューが含まれます。このレイヤーには、データ・マイニング・モデルも含まれます。これらのモデルの結果が導出表に格納されます。モデル自体は、ocdm_miningスキーマに定義されます。

アクセス・レイヤー・オブジェクトを設計およびカスタマイズする場合:

- 「物理構造を設計する場合の一般的な推奨事項」に示されている物理オブジェクトをカスタマイズする一般的なガイドラインに従います。

- 使用しているサイトのビジネス・インテリジェンス・レポートおよび問合せをサポートするため、アクセス・レイヤー・オブジェクトを設計します。第5章「レポートおよび問合せのカスタマイズ」を参照してください。

次のトピックで、アクセス・レイヤー・オブジェクトの設計およびカスタマイズの特化した情報について説明します。

- Oracle Communications Data Modelの導出表

- Oracle Communications Data Modelの集計表

- Oracle Communications Data Modelの次元コンポーネント

- Oracle Communications Data Modelのマテリアライズド・ビュー

Oracle Communications Data Modelの導出表

導出表は、基盤レイヤー表のデータに対する非集計計算の結果を値として含む表です。導出表には、DWD_接頭辞があります。

デフォルトのOracle Communications Data Modelには2つの主要なタイプの導出表があり、これらの表のカスタマイズ方法はタイプごとに異なります。

- ネットワーク要素の日別のBER(Bit Error Rate)およびFER(Frame Error Rate)統計である値を含むDWD_BER_FER_ERR_RATIO_DAY表などの計算結果を保持する表。これらの表のカスタマイズの詳細は、「計算データの新しい導出表の作成」を参照してください。

- データ・マイニング・モデル(DWD_CUST_MNNGなど)の結果表。データ・マイニング・モデルのカスタマイズの詳細は、「Oracle Communications Data Modelデータ・マイニング・モデルのカスタマイズ」を参照してください。

参照:
デフォルトのOracle Communications Data Modelのすべての導出表のリストは、『Oracle Communications Data Modelリファレンス』の導出表トピックを参照してください。データ・マイニング・モデルの結果表である導出表のみのリストは、『Oracle Communications Data Modelリファレンス』のデータ・マイニング・モデルに関する章を参照してください。

計算データの新しい導出表の作成

フィットギャップ分析の実行中にデフォルトの導出表で示されない計算データのニーズを確認した場合、新しい表を定義してこのニーズを満たすことができます。これらの表を設計する場合、導出表にDWD_接頭辞を使用する規則に従って表の名前を付けます。

Oracle Communications Data Modelデータ・マイニング・モデルのカスタマイズ

デフォルトのocdm_sysスキーマの導出表(DWD_)の一部は、デフォルトのOracle Communications Data Modelで定義されているデータ・マイニング・モデルの結果です。これらのモデルは、Oracle Communications Data Modelにも付属するデフォルトのocdm_miningスキーマに定義されています。

すべてのOracle Communications Data Modelマイニング・モデルは、ocdm_miningスキーマに定義されているマテリアライズド・ビューをソース入力として使用します。これらのマテリアライズド・ビューは、$ORACLE_HOME/ocdm/pdm/mining/srcにあるocdm_mining_etl.sqlファイルで定義されます。異なるマイニング・モデルは異なるソース・マテリアライズド・ビューを使用します。

カスタマイズされたOracle Communications Data Modelウェアハウスを作成する場合、次の方法でデータ・マイニング・モデルをカスタマイズできます。

- 「Oracle Communications Data Modelの新しいデータ・マイニング・モデルの作成」で説明するように、新しいモデルを作成します。

- 「Oracle Communications Data Modelデータ・マイニング・モデルの変更」で説明するように、既存のモデルを変更します。

関連項目:
「チュートリアル: チャーン予測モデルのカスタマイズ」

Oracle Communications Data Modelの新しいデータ・マイニング・モデルの作成

新しいデータ・マイニング・モデルを書き込む手順は、次のとおりです。

1. ocdm_miningスキーマにモデルへの入力として使用できるマテリアライズド・ビューの定義が含まれていることを確認します。必要に応じて、新しいマテリアライズド・ビューを定義します。

2. 任意のデータ・マイニング・モデルとしてモデルを作成します。『Oracle Data Mining概要』の手順に従います。モデルをocdm_miningスキーマに追加します。

3. モデルに必要な物理表をocdm_sysスキーマに追加します。「物理モデルをカスタマイズする場合の規則」に記載されたネーミング規則に従って、結果表にDWD_接頭辞を使用します。

4. ocdm_miningスキーマでは、SELECT権限を手順3で作成した結果表に付与します。

5. Intra-ETLを変更して、データ・マイニング・モデルの使用をサポートします。

Oracle Communications Data Modelデータ・マイニング・モデルの変更

Oracle Communications Data Modelマイニング・モデルをカスタマイズするには、次の手順に従います。

1. マイニング・モデルへの入力として使用されるソース・マテリアライズド・ビューの定義を変更します。

2. Oracle Communications Data Modelマイニング・パッケージを呼び出して、モデルを再度トレーニングします。

3. モデルが新しい定義(たとえば、新しい列の追加など)を反映していることを確認します。

例3-1 Oracle Communications Data Modelのマイニング・モデルへの新しい列の追加

新しい列をcreate_churn_svm_modelに追加するには、次の手順に従います。

1. 新しい列をcreate_churn_svm_modelへの入力として使用される次のマテリアライズド・ビューに追加します。

DMV_CUST_CHRN_SRC_SRC
DMV_CUST_CHRN_SRC_PRD
DMV_CUST_CHRN_SRC_TST
DMV_CUST_CHRN_APPLY_ALL

2. 次の文を発行して、モデルをトレーニングします。

ocdm_mining.create_churn_svm_model( MONTH_CODE );

3. 次の文を実行して結果表を問い合せて、新しい列名が問合せ結果に含まれていることを確認します。

SELECT attribute_name FROM TABLE(Oracle Communications Data Model
SELECT ATTRIBUTE_SET ROM TABLE(DBMS_DATA_MINING.GET_MODEL_DETAILS_SVM('OCDM_CHURN_SVM'))
WHERE CLASS='1' );

関連項目:
「Oracle Communications Data Modelウェアハウスのデータのリフレッシュ」、「データ・マイニング・モデルの作成のトラブルシューティング」および付録B「Oracle Communications Data Modelのユーザー権限の操作」

チュートリアル: チャーン予測モデルのカスタマイズ

Oracle Communications Data Modelの基盤レイヤーおよび導出表を移入したら、より高度な分析および予測のための事前作成済のOracle Communications Data Modelマイニング・モデルを利用できます。

このチュートリアルは、移入されたOracle Communications Data Modelウェアハウスに基づいて次の3か月のサービスを終了する顧客(チャーン顧客)を予測する方法を示します。事前作成済のOracle Communications Data Modelマイニング・モデルを使用すると、従来の最初から作成するマイニング・プロジェクトで行う必要があるすべてのデータ準備、トレーニング、テストおよび適用プロセスを実行することなく、顧客の予測結果を簡単かつ迅速に確認できます。

参照:
Oracle Databaseマイニング・トレーニングおよびスコアリング(適用)プロセスの詳細は、『Oracle Data Mining概要』を参照してください。

最初にマイニング・モデルを生成した後、時間の経過とともに顧客の情報および動作が変更されます。したがって、最新の顧客および使用データに基づいて以前にトレーニングしたマイニング・モデルをリフレッシュする必要があります。このチュートリアルのプロセスに従って、マイニング・モデルをリフレッシュして最新の顧客情報の予測を取得できます。

このチュートリアルは、Oracle Communications Data ModelマイニングAPIを介してチャーン予測モデルを生成する方法を示します。トレーニング・プロセスで様々なパラメータを使用するか、より高度な方法でモデルをカスタマイズするため、Oracle Data Minerを使用して同じ作業を実行することもできます。

このチュートリアルは、次の手順で構成されています。

- チュートリアルの前提条件

- 環境の準備

- チャーン予測モデルの生成

- 結果のチェック

チュートリアルの前提条件

このチュートリアルの開始する前に:

1. Oracle Data Miner 11gリリース2の使用に関するOracle by Example(OBE)チュートリアルを確認します。このチュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

2. Oracle Communications Data Modelをインストールします。

3. 実表、参照表および検索表を移入します。

4. Intra-ETLを実行します。
少なくとも次の表に有効なデータが含まれていることを確認します。

DWD_ACCT_STTSTC

DWD_VAS_SBRP_QCK_SUMM

DWR_BSNS_MO

DWR_CUST

DWR_HH

DWR_JB

注意:
実際の顧客データを移入しないでOracle Communications Data Modelマイニング・モデルを学習するだけの場合、次の手順に従って、サンプル・データを使用できます。

1. インストール中に2007年から2008年の範囲を含むカレンダ・データが生成されたことを確認します。たとえば、「20070101」から開始する5年間のパラメータは、この条件を満たします。

2. サンプル・データ(ocdm.4.mining.dmp.gz)をダウンロードして、そのデータを新しいocdm_sysスキーマにインポートします。

環境の準備

このチュートリアルには、移入された有効なOracle Communications Data Modelウェアハウスが必要です。

Oracle By Example:
SQL Developerの使用の詳細は、Oracle SQL Developer 3.0の概要に関するチュートリアルを参照してください。このチュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

環境を準備するには、次の手順に従います。

1. SQL Developerで、ocdm_sysおよびocdm_miningスキーマに接続します。

ヒント:
$ORACLE_HOME/sqldeveloperの下のOracle Databaseインストールで、SQL Developerを確認できます。

2. ocdm_sysスキーマに接続したら、そのスキーマのすべての表を確認できます。「表」を右クリックしてフィルタを適用し、リストを絞り込むことができます。
図prep2.gifの説明

3. (オプション)「環境の準備」に示されているように、表に固有のデータを移入していない場合は、サンプル・データで試行できます。サンプル・データをダウンロードしたら、データをインポートする次の手順に従います。

1. 次の文を発行して、dbaをocdm_sysに付与します。

grant dba to ocdm_sys.

2. チュートリアルで使用される表のすべての外部キーを無効にします。

ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_CS5_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_POT_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLCS_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_SJ_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_SEG_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLCT_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_LAN_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_AL1_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_PT_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_BLC_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLMS_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLJ_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLG_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_HOU1_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLE_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_DLN_FK".
ALTER TABLE "DWR_CUST" DISABLE CONSTRAINT "CI_OI_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_CI_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_BM_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_RSCR_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_AL1_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DAB_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DLCRB_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DLCC_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DAS_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_PM_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DOBU_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_CR1_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_LAB_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_ACCT_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_CHR_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DLAON_FK".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_DLCT_FK1".
ALTER TABLE "DWD_ACCT_STTSTC" DISABLE CONSTRAINT "ACS_GEOC_FK1".
ALTER TABLE "DWD_VAS_SBRP_QCK_SUMM" DISABLE CONSTRAINT "VS_AM_FK".
ALTER TABLE "DWD_VAS_SBRP_QCK_SUMM" DISABLE CONSTRAINT "VS_CI_FK".
ALTER TABLE "DWD_VAS_SBRP_QCK_SUMM" DISABLE CONSTRAINT "VS_BM_FK".
ALTER TABLE "DWD_VAS_SBRP_QCK_SUMM" DISABLE CONSTRAINT "VS_DLCT_FK1".

3. 次の文を発行して、サンプル・ダンプをocdm_sysスキーマにインポートします。

imp ocdm_sys/ocdm_sys@tnsname file=ocdm.4.mining.dmp full=y ignore=y

4. 固有の顧客データまたはサンプル・データの有効なデータが含まれている表を確認します。
図prep3.gifの説明

5. DWR_CUST表を確認します。
図prep4.gifの説明

6. 次の各表をクリックして、表が正しく移入されていることを確認します。

DWD_ACCT_STTSTC

DWD_VAS_SBRP_QCK_SUMM

DWR_BSNS_MO

DWR_CUST

DWR_HH

DWR_JB

7. 「チャーン予測モデルの生成」の説明に従ってモデル生成機能を実行する前に、DWD_CUST_MNNGおよびDWD_CUST_PROD_AFFLTN結果表が空であることを確認します。

チャーン予測モデルの生成

このチュートリアルは、Oracle Communications Data ModelマイニングAPIの2つのプロシージャを使用します。

- ocdm_sysスキーマ表からマイニング・ソース表を移入するpkg_ocdm_mining.refresh_mining_source。

- モデルをトレーニングして予測の結果を生成するpkg_ocdm_mining.create_churn_svm_model。

プロシージャを使用するには、次の手順を実行します。

1. 次のSQL文を実行して、Oracle Communications Data Modelマイニング・ソース表をリフレッシュします。

select count (*) from dmv_cust_chrn_src_all;
exec pkg_ocdm_mining.refresh_mining_source;
select count (*) from dmv_cust_chrn_src_all;

これらの文は、リフレッシュ前の表の数を表示します。

表をリフレッシュして文を再実行し、リフレッシュ後の表の数を表示します。

2. 次のSQL文を実行して、チャーン予測モデルを生成します。

select count(*) from dwd_cust_mnng;
select count(*) from dwd_chrn_svm_factor;
exec pkg_ocdm_mining.create_churn_svm_model;
select count(*) from dwd_cust_mnng;

次の文を実行します。

- 生成前のレコード数を表示します。

- モードを生成します。

- 生成後の数を表示します。

注意:
このチュートリアルはすべてのモデルをリフレッシュしません。1つのチャーン予測モデルのみリフレッシュします。最新の顧客データに基づいてすべてのデフォルトのマイニング・モデルをリフレッシュするには、「Oracle Communications Data Modelウェアハウスのデータのリフレッシュ」の指示に従います。

結果のチェック

モデルのリフレッシュ、トレーニングおよび生成の後、次の手順を実行して、ocdm_sysスキーマのDWD_CUST_MNNG結果表を確認します。

1. 次の問合せを発行します。

Select cust_key, prdct_churn_svm_ind, prdct_churn_svm_prob From dwd_cust_mnng where rownum < 10;

図result1.gifの説明

2. CUST_KEYで識別される顧客ごとに、PRDCT_CHRN_SVM_IND列で顧客が次の3か月チャーンするかどうかのブール予測が示されます。ゼロ(0)は非チャーン顧客、(1)はチャーン顧客を表します。PRDCT_CHURN_SVM_PROB列は、顧客がチャーンする頻度の詳細な可能性(0から1)を示します。

3. (オプション)Oracle Business Intelligence Suite Enterprise Edition 11gのOracle Communications Data Modelサンプル・レポートもインストールしている場合、Oracle Business Intelligence Suite Enterprise Editionレポートとしても結果を表示できます。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

図result2.gifの説明

Oracle Business Intelligence Suite Enterprise Editionレポートでは、契約ARPU、債務値などの顧客収益情報が予測結果とともに示されます。

Oracle Communications Data Modelの集計表

集計表は、実表または導出表より1つ上位のレベルにデータを集計または「ロールアップ」する表です。デフォルトのOracle Communications Data Modelの集計表は実際マテリアライズド・ビューで、DWA_接頭辞があります。これらの集計表は、スノーフレーク・スキーマのファクト表で示されるビューと同様のデータのビューを提供します。

デフォルトのOracle Communications Data Modelは、複数の集計表を定義しています。たとえば、DWA_BER_FER_ERR_RATIO_MONTH表は、DWD_BER_FER_ERR_RATIO_DAY表の値を月レベルに集計します。

参照:
デフォルトのOracle Communications Data Modelの集計表のリストは、『Oracle Communications Data Modelリファレンス』の「集計表」トピックを参照してください。

フィットギャップ分析の実行中にデフォルトの集計表で示されない単純な集計データのニーズを確認した場合、新しいマテリアライズド・ビューを定義できます。これらの表を設計する場合、次の点を考慮します。

- 単一のレベルのみを集計するマテリアライズド・ビューの問合せを作成します。たとえば、長期間の集計の日次から月次のみの集計などです。

注意:
多くのレベル(たとえば、時間、月、四半期、年など)または異なる階層(たとえば、時間ディメンションの会計およびカレンダ階層など)を集計する必要がある場合、DWA_表を定義しないで、かわりにOLAPキューブを作成して集計を定義します。

関連項目:
「Oracle Communications Data Modelのマテリアライズド・ビュー」および「Oracle Communications Data Modelの新しいOracle OLAPキューブの定義」

- 「物理オブジェクトの一般的なネーミング規則」に記載された規則に従って表の名前を付け、DWA_接頭辞を使用します。

Oracle Communications Data Modelの次元コンポーネント

固有の長所と短所を持つ各スタイル、従来の3NFおよび次元を使用した特定のデータ・ウェアハウスに対する最適なモデリング・アプローチに関して多くの議論がよくあります。傾向として、データ・ウェアハウスは、1つのみに依存しないで各モデル・タイプの利点をさらに取り込む必要があります。これはOracle Communications Data Modelの設計で採用されたアプローチです。Oracle Communications Data Modelの基盤レイヤーは3NFモデルです。デフォルトのOracle Communications Data Modelは、データの次元モデルも提供します。この次元モデルのデータは、詳細トランザクション情報を保持するのではなく、データを要約および集計する視点です。

デフォルトのOracle Communications Data Modelの次元モデルをカスタマイズする前に、次のトピックを参照して次元モデリングについてよく理解します。

- 次元モデルの特性

- リレーショナル・スターおよびスノーフレーク表の特性

- OLAP次元モデルの特性

- Oracle Communications Data ModelのOLAPキューブの特性

- Oracle Communications Data Modelの新しいOLAPキューブの定義

- Oracle Communications Data ModelのOracle OLAPキューブの変更

- Oracle Communications Data Modelの予測キューブの作成

- Oracle Communications Data Modelのキューブ・パーティション化戦略の選択

- Oracle Communications Data Modelのキューブ・データのメンテナンス方法の選択

次元モデルの特性

次元モデルに簡素性が備わっているのは、実在するビジネス・エンティティを表すオブジェクトを定義しているためです。分析者は、調査したいビジネス・メジャー、データに意味を与えているディメンションや属性、およびビジネスのディメンションがレベルや階層に編成されている方法がわかります。

つまり、次元モデルは次のオブジェクトを識別します。

- メジャーメジャーは、売上、経費、インベントリなどの定量的なビジネス・データを格納します。メジャーは、「ファクト」と呼ばれることがあります。メジャーは1つ以上のディメンションによって編成され、問合せ時に格納または計算される場合があります。

- ストアド・メジャーストアド・メジャーは、リーフ・レベルでロードおよび格納されます。通常、格納されるサマリー・データの割合もあります。格納されないサマリー・データは、問合せ時に動的に集計されます。

- 計算済メジャー。計算済メジャーは、問合せ時に動的に計算される値のメジャーです。計算ルールのみ、データベースに格納されます。一般的な計算には、比率、差、移動和、平均などのメジャーが含まれます。計算にはディスク・ストレージ領域が必要なく、データのメンテナンスに必要な処理時間を拡張しません。

- ディメンションディメンションは、ユーザーのビジネス上の疑問に答えられるようにデータを分類する構造です。よく使用されるディメンションとしてCustomers、Products、Timeがあります。ディメンションの構造は、親子リレーションシップに基づいて階層的に編成されます。これらのリレーションシップで次のことが可能です。

- レベル間の移動。
ディメンションの階層では、下位レベルのドリルダウンまたは上位レベルの移動(ロールアップ)を行うことができます。通常、時間ディメンション・メンバー2005のドリルダウンは、2005年第1四半期から第4四半期の四半期に移動します。カレンダ年階層では、2005年第1四半期のドリルダウンは05年1月から05年3月の月に移動します。このようなリレーションシップにより、ユーザーは大量の多次元データを簡単に移動できます。

- 子値から親値の集計。
親は、子の集計を表します。下位レベルのデータ値は、上位レベルのデータ値に集計されます。ディメンションは、異なるレベルの集計のデータを効率的に操作して分析および表示するため、階層的に構造化されます。

- 親値から子値の割当て。
集計の反対は割当てで、予算計画や同様の適用例で頻繁に使用されます。ここで、階層の役割は、使用例の中で特に予算の「トップダウン」の割当ての特定のディメンション・メンバーの子および子孫を識別することです。

- 計算用のメンバーのグループ化。
シェアおよび指標計算では、階層リレーションシップ(たとえば、各製品が寄与する全体の利益の割合、特定のカテゴリの製品収益のシェア割合、小売場所の地理的地域の割合としてのコストなど)を利用します。

ディメンション・オブジェクトにより、ディメンション情報を階層形式に編成してグループ化できます。これは、制約では表すことのできない列間または列グループ(階層レベル)間の1:nの関係を表します。階層内でのレベルを上げることはデータのロールアップと呼ばれ、レベルを下げることはデータのドリルダウンと呼ばれます。

次元モデルを実装できる2つの方法があります。

- スター・スキーマ構成のリレーショナル表次元モデルを実装するこの従来の方法は、「リレーショナル・スターおよびスノーフレーク表の特性」で説明します。

- Oracle OLAPキューブOracle Communications Data Modelで提供される物理モデルは、Oracle OLAPキューブを使用してデータのディメンションの視点を示します。この次元モデルは、「OLAP次元モデルの特性」で説明します。

リレーショナル・スターおよびスノーフレーク表の特性

リレーショナル表の場合、次元モデルは、以前からスター・スキーマまたはスノーフレーク・スキーマとして実装されています。ディメンション表(階層、レベルおよび属性の情報を含む)は、1つ以上のファクト表に結合します。ファクト表は定量的なビジネス・メジャー(売上、経費およびインベントリなど)を格納する大きい表で、通常ディメンション表に対する外部キーがあります。ディメンション表(検索表または参照表とも呼ぶ)には、データ・ウェアハウスの比較的静的または記述的なデータが含まれます。

ドリル・パス、階層および問合せプロファイルはデータではなくデータ・モデル自体に埋め込まれるため、スター・スキーマは物理モデルに似ています。これにより、少なくとも部分的にエンド・ユーザーにとってモデルの操作が容易になります。通常、スター・スキーマには、小さなディメンション表で囲まれた大きいファクト表があります。ディメンション表は頻繁に変更されません。ユーザーが必要とするほとんどの情報は、ファクト表にあります。したがって、スター・スキーマは、3NFモデルよりも表の結合が少なくなります。

中央から点が放射状に伸びており、ダイアグラムが星に似ているため、スター・スキーマと呼ばれます。星の中心は1つ以上のファクト表で構成されており、星の点はディメンション表です。

図3-1 スター・スキーマ・ダイアグラム

「図3-1 スター・スキーマ・ダイアグラム」の説明

スノーフレーク・スキーマは、ディメンション表を複数の表にさらに正規化して分割する場合に単純なスター・スキーマを少し変化させたものです。スノーフレークはディメンションにのみ影響しファクト表には影響しないため、概念的にスター・スキーマと同等とみなされます。スノーフレーク・ディメンションは、異なる粒度のファクト表がある場合に便利で実際に必要です。月レベルの導出表または集計表(またはマテリアライズド・ビュー)は、デフォルトの(下位の)日レベルのスター・ディメンション表ではなく月レベルのスノーフレーク・ディメンション表に関連付ける必要があります。

関連項目:
「リレーショナル・ディメンション表の宣言」および「リレーショナル・ディメンション表の検証」

リレーショナル・ディメンション表の宣言

リレーショナル表がファクト表のディメンションとして機能する場合、(必要でなくても)ディメンションとして表を宣言することをお薦めします。定義されたディメンションは大きなパフォーマンスの利点があり、より複雑なタイプのリライトの使用をサポートします。

ディメンションの構造を定義および宣言するには、CREATE DIMENSIONコマンドを使用します。LEVEL句を使用して、ディメンション・レベルの名前を識別します。

リレーショナル・ディメンション表の検証

データ・ウェアハウスのディメンション・データのデータ品質を向上するには、ディメンション・データの変更後のディメンション・メンバー間のリレーションシップの宣言情報を検証することをお薦めします。

この検証を実行するには、DBMS_DIMENSIONパッケージのVALIDATE_DIMENSIONプロシージャを使用します。VALIDATE_DIMENSIONプロシージャでエラーが検出されると、プロシージャはエラーをDIMENSION_EXCEPTIONS表に書き込みます。VALIDATE_DIMENSIONプロシージャで識別される例外を確認するには、DIMENSION_EXCEPTIONS表の問合せを実行します。

通常の増分ディメンション・ロード・スクリプトの後処理の手順として、VALIDATE_DIMENSIONプロシージャのコールをスケジュールできます。マテリアライズド・ビューのリフレッシュを通じてデータ・モデルの導出表または集計表をリフレッシュするコール、Intra-ETLパッケージ・コールの前に、これを実行できます。

OLAP次元モデルの特性

Oracle OLAPキューブは、リレーショナル・スター表と同様のデータを論理的に表しますが、データは実際に多次元配列に格納されます。ディメンション表と同様、キューブ・ディメンションはメンバーを階層、レベルおよび属性に編成します。キューブは、メジャー(ファクト)データを格納します。ディメンションは、キューブのエッジを形成します。

Oracle OLAPは、Oracle Databaseに埋め込まれたOLAPサーバーです。Oracle OLAPにより、複数のディメンションにまたがってデータを分析する際に、固有の多次元格納および高速な応答時間を実現できます。データベースでは、時系列計算、予測、加算および非加算の演算子や割当て操作による高度な集計など、多様な形で分析を行うことができます。

Oracleでは、多次元オブジェクトおよび分析をデータベースに統合することにより、両者の利点を活かし、Oracleデータベースの信頼性、可用性、セキュリティ、スケーラビリティとともに多次元分析機能を実現しています。

Oracle OLAPはOracle Databaseに完全に統合されています。これは、技術レベルでは次のことを意味します。

- OLAPエンジンは、Oracle Databaseのカーネルで実行されます。

- ディメンション・オブジェクトは、固有の多次元形式でOracle Databaseに格納されます。

- キューブなどのディメンション・オブジェクトは、Oracleデータ・ディクショナリの主要なデータ・オブジェクトです。

- データ・セキュリティは、Oracle Databaseのユーザーとロールに対して権限の付与および取消しを行う、標準的な方法で管理されます。

- OLAPキューブ、ディメンションおよび階層は、リレーショナル・ビューとしてアプリケーションに公開されます。そのため、「Oracle OLAPキューブ・ビュー」および第5章「レポートおよび問合せのカスタマイズ」に示されているように、アプリケーションはSQLを使用してOLAPオブジェクトを問い合せることができます。

- 「キューブ・マテリアライズド・ビュー」の説明に従ってマテリアライズド・ビューになるように、Oracle OLAPキューブを拡張できます。

関連項目:
『Oracle OLAPユーザーズ・ガイド』および「Oracle Communications Data ModelのOLAPキューブの特性」

Oracle OLAPを使用する利点

Oracle OLAPを使用することの利点は多く、Oracle OLAPは、簡素化によるメリットをもたらし、1つのデータベース、標準の管理およびセキュリティ機能、標準のインタフェースや開発ツールを提供します。

Oracle OLAP次元データ・モデルは、高度に構造化されています。構造とは、データ間の関係を決定し、データの問合せ方法を制御する規則のことを意味します。キューブは次元モデルの物理的な実装なので、次元問合せにあわせて高度に最適化されています。OLAPエンジンは、元々備えているこのディメンション性を利用することにより、きわめて効率的にクロスキューブ結合(行間計算の場合)、外部結合(時系列分析の場合)および索引付けを実行します。ディメンションは、メジャーに事前結合されます。キューブの基盤となるこのテクノロジは、索引付けされた多次元配列モデルをベースにしており、この多次元配列モデルが直接的なセル・アクセスを可能にしています。

OLAPエンジンによる次元オブジェクトの処理は、SQLエンジンによるリレーショナル・オブジェクトの処理と同様に行われます。ただし、OLAPエンジンは分析関数の計算に関して、次元オブジェクトは分析に関してそれぞれ最適化されているため、OLAPでは、分析関数および行関数の計算を、SQLよりもはるかに高速に実行できます。

Oracle OLAPは次元モデルにより、OracleBI Discoverer Plus OLAP、OracleBI Spreadsheet Add-In、Oracle Business Intelligence Suite Enterprise Edition、BusinessObjects EnterpriseおよびCognos ReportNetなど、ビジネス・インテリジェンス用のハイエンドなツールやアプリケーションをサポートすることが可能になっています。

Oracle OLAP次元オブジェクト

Oracle OLAP次元オブジェクトには、キューブ、メジャー、ディメンション、階層、レベルおよび属性が含まれます。OLAP次元オブジェクトの詳細は、『Oracle OLAPユーザーズ・ガイド』で説明されています。図3-2に、オブジェクト間の一般的な関係を示します。

図3-2 OLAPの次元モデルの図

「図3-2 OLAPの次元モデルの図」の説明

Oracle OLAPキューブ・ビュー

OLAPキューブを定義する場合、Oracle OLAPは、キューブ、ディメンションおよび階層の一連のリレーショナル・ビューを自動的に生成します。

- キューブ・ビュー。各キューブには、キューブ内のすべてのメジャーと計算済メジャーのデータを示すキューブ・ビューが1つあります。キューブ・ビューは、スター・スキーマまたはスノーフレーク・スキーマ内のファクト表のように使用できます。ただし、キューブ・ビューには、ディテール・レベルのデータの他にすべてのサマリー・データも含まれます。キューブ・ビューのデフォルトの名前はcube_VIEWです。

- ディメンション・ビューと階層ビュー各ディメンションには、ディメンション・ビューが1つと、そのディメンションに関連付けられている各階層の階層ビューがあります。ディメンション・ビューのデフォルトの名前はdimension_VIEWです。階層ビューのデフォルトの名前はdimension_hierarchy_VIEWです。

これらのビューは、スター・スキーマにおけるファクト表とディメンション表と同様の関係にあります。キューブ・ビューはファクト表と同じ機能を持ち、階層ビューとディメンション・ビューはディメンション表と同様に機能します。通常の問合せでは、階層ビューまたはディメンション・ビューのいずれかとキューブ・ビューを結合します。

SQLアプリケーションでこれらのビューを問い合せることにより、分析担当者や意思決定者はこれらのオブジェクトの情報量に富んだ内容を表示できます。また、実表などのシステム生成ビューを使用して、ご使用のアプリケーションに必要な構造に従ったカスタム・ビューを作成できます。

関連項目:
『Oracle OLAPユーザーズ・ガイド』および第5章「レポートおよび問合せのカスタマイズ」の次元オブジェクトの問合せの説明。

キューブ・マテリアライズド・ビュー

マテリアライズド・ビューにするため、Oracle OLAPキューブを拡張できます。このように拡張されたキューブはキューブ・マテリアライズド・ビューと呼ばれ、CB$接頭辞を使用します。キューブ・マテリアライズド・ビューはOracle Databaseマテリアライズド・ビュー・サブシステムを介して段階的にリフレッシュでき、ソース表に対する問合せの透過的リライトの対象として使用できます。

キューブ・マテリアライズド・ビューに関連付けられたOLAPディメンションも、マテリアライズド・ビュー機能を使用して定義されます。

キューブ・マテリアライズド・ビューの必要なキューブ特性

キューブ・マテリアライズド・ビューとして設定するキューブは、次の条件を満たしている必要があります。

- キューブのすべてのディメンションに、少なくとも1つのレベルと、1つのレベルベース階層が存在する。不規則階層およびスキップレベル階層はサポートされない。ディメンションがマップされている必要がある。

- キューブのすべてのディメンションで同じ集計演算子(SUM、MIN、MAXのいずれか)を使用している。

- ディメンションとメジャーがそれぞれ1つ以上存在する。

- 定義とマップが完全に行われている。たとえば、キューブに5つのメジャーがある場合、その5つすべてがソース表にマップされている。

- キューブのデータ型が、NUMBER、VARCHAR2、NVARCHAR2またはDATEである。

- ソースのディテール表で、ディメンションおよびRELY制約がサポートされている。これらが定義されていない場合は、リレーショナル・スキーマ・アドバイザを使用して、ディテール表に対してこれらを定義するスクリプトを生成できる。

- 圧縮されている。

- 計算済メジャーは使用できるが、キューブ・スクリプト内のより高度な分析機能は使用できない。

マテリアライズド・ビュー機能の追加

マテリアライズド・ビュー機能をOLAPキューブに追加するには、次の手順を実行します。

1. Analytic Workspace Managerで、ocdm_sysスキーマに接続します。

2. キューブ・リストから、有効にするキューブを選択します。

3. 右ペインで、「マテリアライズド・ビュー」タブを選択します。

4. 「キューブのマテリアライズド・ビューのリフレッシュを有効化」を選択し、「適用」をクリックします。

注意:
予測キューブのキューブ・マテリアライズド・ビューは有効にできません。

Oracle By Example:
OLAPキューブの操作の詳細は、次のOBEチュートリアルを参照してください。

- 「OLAP 11gキューブの問合せ」

- 「Oracle BI Enterprise EditionによるOracle OLAP 11gの使用」

チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

関連項目:
『Oracle OLAPユーザーズ・ガイド』

Oracle Communications Data ModelのOLAPキューブの特性

Oracle Communications Data Modelのデフォルトのアクセス・レイヤーは、Oracle OLAPキューブを使用してデータのディメンションの視点を示します。

デフォルトのocdm_sysスキーマで定義されるOLAPキューブがあります。これらのキューブには、「OLAP次元モデルの特性」で説明されている一般的な特性があります。具体的に、Oracle Communications Data ModelのOLAPキューブには次の特性があります。

- すべてのデフォルトのOLAPキューブは、マテリアライズド・ビューであるDWA_表のデータとともにロードされます。

- Analytical Workspace Manager(AWM)クライアント・ツールを使用して、キューブが定義および作成されました。

- リレーショナル・ビュー(_VIEW接尾辞を使用)は、各OLAPキューブに定義されます。

- Oracle Communications Data ModelのすべてのOLAPキューブは、キューブ・マテリアライズド・ビュー(つまり、CB$オブジェクト)です。

注意:
インストールの直後に、OLAPキューブの基になるすべてのマテリアライズド・ビューがデフォルトで無効になります。キューブ・マテリアライズド・ビューを有効にするには、「マテリアライズド・ビュー機能の追加」で概説する手順に従う必要があります。

Oracle Communications Data ModelのカスタマイズしたバージョンのOLAPキューブの使用の詳細は、『Oracle OLAPユーザーズ・ガイド』および次のトピックを参照してください。

- Oracle Communications Data Modelの新しいOLAPキューブの定義

- Oracle Communications Data ModelのOracle OLAPキューブの変更

- Oracle Communications Data Modelの予測キューブの作成

- Oracle Communications Data Modelのキューブ・パーティション化戦略の選択

- Oracle Communications Data Modelのキューブ・データのメンテナンス方法の選択

Oracle Communications Data Modelの新しいOLAPキューブの定義

新しいOLAPキューブをocdm_sysスキーマに追加できます。一貫性のため、「Oracle Communications Data ModelのOLAPキューブの特性」の説明に従って、これらの新しいキューブを設計および定義します。

次の手順を実行して、新しいキューブを定義します。

1. キューブの「最下位のリーフ」データとして使用する集計表(DWA_)があることを確認します。新しい表の作成の詳細は、「Oracle Communications Data Modelの集計表」を参照してください。

2. AWMを使用して、Oracle Communications Data Modelのカスタマイズしたバージョンの新しいキューブを定義します。『Oracle OLAPユーザーズ・ガイド』のキューブおよびディメンションを作成する指示に従います。
新しいOLAPキューブを設計および定義する場合、「OLAP次元モデルの特性」で提供されている情報および『Oracle OLAPユーザーズ・ガイド』を使用します。また、「リレーショナル・スターおよびスノーフレーク表の特性」で概説するリレーショナル・スター・スキーマ設計に慣れている場合、この知識を利用してOLAPキューブを設計できます。

- ファクト表は、キューブに対応する。

- ファクト表のデータ列は、メジャーに対応する。

- ファクト表の外部キー制約は、ディメンション表に対応する。

- ディメンション表は、ディメンションに対応する。

- ディメンション表の主キーは、ベース・レベルのディメンション・メンバーに対応する。

- ディメンション表の親列は、上位レベルのディメンション・メンバーに対応する。

- ディメンション・メンバーの説明や特性が格納されているディメンション表の列は、属性に対応する。

また、Oracle Communications Data Modelに含まれるサンプル・レポートを参照して、次元モデルを理解できます。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

ヒント:
ソース・データを調査するときに、作成しようとしている次元モデルとの一致度がより高いリレーショナル・ビューを作成することもできます。

3. 「マテリアライズド・ビュー機能の追加」の説明に従って、マテリアライズド・ビュー機能をOLAPキューブに追加します。

関連項目:
『Oracle OLAPユーザーズ・ガイド』、「Oracle Communications Data Modelの新しいOLAPキューブの定義」および『Oracle Communications Data Modelリファレンス』のサンプル・レポート。

Oracle By Example:
OLAPキューブの作成の詳細は、OLAP 11gキューブの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

Oracle Communications Data ModelのOracle OLAPキューブの変更

Oracle Communications Data Modelキューブの一般的なカスタマイズは、キューブのディメンションまたはメジャーを変更します。

すべてのOracle Communications Data Modelキューブは接頭辞がDWA_の表からデータをロードするため、1つのキューブのメジャーまたはディメンションを変更する場合は、次の手順に従う必要があります。

1. 『Oracle Communications Data Modelリファレンス』の情報を使用して、OLAPキューブの移入元のDWA_表を識別します。

2. 手順1で識別したDWA_表の構造を変更します。

3. OLAPキューブとキューブ・マテリアライズド・ビューを変更して、新しい構造を反映します。

Oracle Communications Data Modelの予測キューブの作成

Oracle Communications Data Modelの予測キューブを作成する手順は、次のとおりです。

1. 「Oracle Communications Data Modelの新しいOracle OLAPキューブの定義」の説明に従って、予測の結果を含むキューブを作成します。

注意:
Oracle Communications Data Modelの予測キューブのマテリアライズド・ビューは有効にできません。

2. 『Oracle OLAP DMLリファレンス』の説明に従って、OLAP DML予測コンテキスト・プログラムを作成します。

Oracle Communications Data Modelのキューブ・パーティション化戦略の選択

パーティション化は物理的にキューブの内容を格納する方法です。これによって、大きいキューブのパフォーマンスが次のように向上します。

- データ構造をコンパクトに保つことで、スケーラビリティが向上します。各パーティションは、小さなメジャーのように機能します。

- 関連するデータはまとめて格納されるため、問合せまたはメンテナンスの際に対象となるデータセットが小さくて済みます。

- データ・メンテナンス時のパラレル集計が可能になります。各パーティションを別々のプロセスで集計できます。

- 記憶域上の古いデータの削除が容易になります。古いパーティションを削除し、新しいパーティションを追加できます。

パーティションの数は、キューブへのデータのロードやデータの集計に割当て可能なデータベース・リソースに影響します。十分なリソースが割り当てられていれば、複数のパーティションを同時に集計できます。

ソース表の分析とパーティション化方法の決定は、キューブ・パーティショニング・アドバイザによって行われます。キューブ・パーティショニング・アドバイザの推奨する方法を採用できますが、ユーザー独自のパーティション化方法を決めることもできます。

パーティション化戦略が主にライフサイクル管理を考慮して作成される場合は、時間ディメンションでキューブをパーティション化する必要があります。こうすれば、古い期間をまとめて削除し、新しい期間を新しいパーティションに追加できます。キューブ・パーティショニング・アドバイザの時間オプションを選択すると、Timeディメンションの階層とレベルをパーティション化に使用するよう推奨されます。

キューブをパーティション化するレベルは、ロード・パフォーマンスと問合せパフォーマンスのトレードオフに基づいて決定されます。

通常、非常に低いレベル(たとえば、時間ディメンションの日レベルなど)ではパーティション化しません。実行すると、非常に多くのパーティションをロード時に定義する必要があり、初期ロードまたは履歴ロードの速度が低下するためです。また、多数のパーティションの結果、アナリティック・ワークスペース接続時間が異常に長くなり、時系列ベースの計算の速度が低下する場合があります。また、四半期累積メジャー(現在までの1四半期メジャー)は、90または91のパーティションにアクセスして、1つの顧客および組織の特定の値を計算する必要があります。パーティション・ディメンションのパーティション・レベルより上位のすべてのディメンション・メンバー(デフォルト以外の階層に属するメンバーを含む)は、単一のデフォルトのテンプレートに存在します。すべての上位レベルのメンバーがデフォルトのテンプレートに格納されるため、日レベルのパーティション化は非常に重くなります。ただし、OLAPキューブ・ロード頻度が日単位の場合のDAYのパーティション化の利点は、毎日ファクト表の新しいパーティションからOLAPキューブの単一のパーティションにロードするだけで済むことです。これにより、キューブがマテリアライズド・ビュー対応でマテリアライズド・ビュー・ログを含む場合に割合ベースのリフレッシュを有効にできるので、ロード・パフォーマンスが大幅に向上します。

推奨: キューブ・パーティション化戦略

通常、異なるロードと問合せパフォーマンス要件の適切な妥協案として、パーティション・レベルとしてMONTHなどの中間レベルを使用します。月内の時系列計算(現在までの週、現在までの月など)は高速で、現在までの年などの上位レベルの計算は最大で12のパーティションを参照する必要があります。また、このように、月単位のパーティションが各月の最初の初期ロード中に一度だけ定義および作成され、その月の後続のロードのたびに再使用されます。集計プロセスが特定の日レベルのかわりに月レベルでトリガーされ、現在の月の以前にロードした日の余分な集計が毎回発生する可能性がありますが、結果は正常なロードおよび問合せパフォーマンスになります。

関連項目:
パーティション戦略の選択の説明は、『Oracle OLAPユーザーズ・ガイド』、「Oracle Communications Data Modelの索引とパーティション索引」および「パーティション化とマテリアライズド・ビュー」を参照してください。

Oracle Communications Data Modelのキューブ・データのメンテナンス方法の選択

データの次元モデルの開発中に、オブジェクト定義またはマッピングのエラーをすぐに検出して修正するため、作成後すぐに各オブジェクトをマップおよびロードすることをお薦めします。

ただし、本番環境では、できるだけ簡単で時間もかからない定期的なメンテナンスが必要です。このような場合は、データのメンテナンス方法を選択できます。キューブはメンテナンス・ウィザードを使用してリフレッシュできます。このウィザードでは、キューブを即時にリフレッシュするか、リフレッシュ処理をジョブとしてOracleジョブ・キューに送るか、またはPL/SQLスクリプトを生成します。スクリプトは手動で実行する以外にも、Oracle Enterprise Managerのスケジューラや、PL/SQLパッケージのDBMS_SCHEDULERなどのスケジューリング・ユーティリティを使用することもできます。生成したスクリプトによって、PL/SQLパッケージのDBMS_CUBEのBUILDプロシージャがコールされます。このスクリプトを編集したり、このパッケージを使用してスクリプトを始めから作成することができます。

複数のプロセスが作成処理に割り当てられている場合、パーティション化されたキューブのデータはパラレルにロードおよび集計されます。この結果は作成ログで確認できます。

さらに、それぞれのキューブに対して次のデータ・メンテナンス方法を使用できます。

- カスタム・キューブ・スクリプト

- キューブ・マテリアライズド・ビュー

既存のマテリアライズド・ビューをキューブに置き換えるように定義した場合は、必ずマテリアライズド・ビューを使用してデータ・メンテナンスを行います。ただし、マテリアライズド・ビュー機能を有効にすると、カスタム・キューブ・スクリプトで実行できる分析の種類が制限されます。

関連項目:
『Oracle OLAPユーザーズ・ガイド』および「マテリアライズド・ビューのタイプおよびリフレッシュ・オプション」

Oracle By Example:
リレーショナル・スター・スキーマへの透過的なアクセスに対してキューブ・マテリアライズド・ビューを使用する方法の例は、次のOBEチュートリアルを参照してください。

- 「OLAP 11gキューブの問合せ」

チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

Oracle Communications Data Modelのマテリアライズド・ビュー

マテリアライズド・ビューは、スキーマ・オブジェクトとして事前に格納またはマテリアライズされた問合せ結果です。物理設計の観点からすると、マテリアライズド・ビューは表やパーティション表に似ており、透過的に使用されパフォーマンスが向上するという点で、索引のような動作をします。

以前は、サマリーを使用する場合、手動でのサマリーの作成、どのサマリーを作成するかの識別、サマリーへの索引付け、サマリーの更新、およびユーザーに対するサマリーのアドバイスに膨大な時間と労力を費やしていました。マテリアライズド・ビューの導入で、データベース管理者はサマリーと同等の1つ以上のマテリアライズド・ビューを作成します。そのため、データベース管理者の作業負荷が軽減され、ユーザーはどのサマリーが定義されているかを把握する必要がなくなっています。かわりに、エンド・ユーザーは、表やビューをディテール・データ・レベルで問い合せます。Oracleサーバーのクエリー・リライト・メカニズムにより、サマリー・テーブルを使用するようにSQL問合せが自動的にリライトされ、問合せから結果を戻すレスポンス時間が短縮されます。

マテリアライズド・ビューは、問合せを実行する前にコストの高い結合および集計操作をデータベース上で事前に計算し、その結果をデータベースに格納することで、問合せのパフォーマンスを改善します。問合せオプティマイザでは、問合せの要求を満たすのに既存のマテリアライズド・ビューが使用可能かどうか、また必要かどうかが自動的に認識されます。

デフォルトのOracle Communications Data Modelは、多くのマテリアライズド・ビューを定義します。デフォルトのocdm_sysスキーマでは、次の表にリストされている接頭辞を使用したオブジェクトを参照して、これらのマテリアライズド・ビューを識別できます。

接頭辞

説明

DWA_

マテリアライズド・ビューの集計表。
参照: デフォルトのデータ・モデルのこれらのオブジェクトのリストは、『Oracle Communications Data Modelリファレンス』の集計表を参照してください。

これらのオブジェクトのカスタマイズの詳細は、「Oracle Communications Data Modelの集計表」を参照してください。

CB$

マテリアライズド・ビュー機能で拡張されるOLAPキューブ。
参照: デフォルトのデータ・モデルのこれらのオブジェクトのリストは、『Oracle Communications Data Modelリファレンス』のOLAPキューブ・マテリアライズド・ビューを参照してください。

OLAPキューブの詳細は、「Oracle Communications Data ModelのOLAPキューブの特性」を参照してください。

注意: このオブジェクトのレポートまたは問合せを実行しないでください。かわりに、OLAPキューブのリレーショナル・ビュー(つまり、_VIEW接尾辞を使用したオブジェクト)にアクセスします。

DMV_

パフォーマンスのために作成された(つまり、集計表やキューブ・マテリアライズド・ビューではない)マテリアライズド・ビュー。
参照: デフォルトのデータ・モデルのこれらのオブジェクトを確認するには、『Oracle Communications Data Modelリファレンス』を参照してください。

次のトピックで、カスタマイズしたOracle Communications Data Modelのマテリアライズド・ビューの使用および作成の詳細について説明します。

- マテリアライズド・ビューのタイプおよびリフレッシュ・オプション

- マテリアライズド・ビューに対する索引付けの選択

- パーティション化とマテリアライズド・ビュー

- マテリアライズド・ビューの圧縮

マテリアライズド・ビューのタイプおよびリフレッシュ・オプション

リフレッシュ・オプションは、マテリアライズド・ビューのタイプごとに異なります。

- 集計を含むマテリアライズド・ビューのリフレッシュ・オプション

- 結合のみを含むマテリアライズド・ビューのリフレッシュ・オプション

- ネステッド・マテリアライズド・ビューのリフレッシュ・オプション

参照:
Oracle OLAPキューブのマテリアライズド・ビューの作成の詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

集計を含むマテリアライズド・ビューのリフレッシュ・オプション

データ・ウェアハウスで、通常マテリアライズド・ビューは集計を含みます。デフォルトのOracle Communications Data Modelの_DWA表は、このタイプのマテリアライズド・ビューです。

集計を含むマテリアライズド・ビューで、高速のリフレッシュが可能です。

- SELECTリストは、すべてのGROUP BY列(存在する場合)を含む必要があります。

- 集計列にCOUNT(*)およびCOUNT(column)が必要です。

- マテリアライズド・ビュー・ログは、マテリアライズド・ビューを定義する問合せで参照されるすべての表に関して存在する必要があります。有効な集計関数は、SUM、COUNT(x)、COUNT(*)、AVG、VARIANCE、STDDEV、MIN、MAXです。また、任意のSQL値式を集計できます。

結合と集計を含むマテリアライズド・ビューの高速リフレッシュは、実表に対してDML(ダイレクト・ロードまたは従来型のINSERT、UPDATEまたはDELETE)を実行した後に可能になります。

マテリアライズド・ビューをON COMMITまたはON DEMANDでリフレッシュするように定義できます。REFRESH ON COMMITを指定した場合は、マテリアライズド・ビューのディテール表に対してDMLを実行するトランザクションがコミットされると、マテリアライズド・ビューが自動的にリフレッシュされます。

REFRESH ON COMMITを指定すると、表のコミットに時間がかかる場合があります。これは、リフレッシュ操作がコミット・プロセスの一部として実行されるためです。したがって、この方法は、多数のユーザーがマテリアライズド・ビューの実表を同時に変更する場合には適していません。

結合のみを含むマテリアライズド・ビューのリフレッシュ・オプション

マテリアライズド・ビューに結合のみが含まれ、集計は含まれません(たとえば、sales表をtimes表およびcustomers表に結合するマテリアライズド・ビューが作成される場合など)。このタイプのマテリアライズド・ビューを作成するメリットは、コストの高い結合が事前に計算されることです。

結合のみを含むマテリアライズド・ビューの高速リフレッシュは、実表に対してDML(ダイレクト・パスまたは従来型のINSERT、UPDATEまたはDELETE)を実行した後に可能になります。

結合のみを含むマテリアライズド・ビューは、ON COMMITまたはON DEMANDでリフレッシュされるように定義できます。ON COMMITの場合、リフレッシュは、マテリアライズド・ビューにある1つのディテール表上でDMLを実行するトランザクションのコミット時に実行されます。

REFRESH FASTを指定する場合、Oracleは、問合せ定義をさらに検証して、いずれかのディテール表が変更された場合の高速リフレッシュの実行を保証します。これらの追加チェックには、次の制限が含まれます。

- 表がパーティション・チェンジ・トラッキングをサポートしないかぎり、マテリアライズド・ビュー・ログがディテール表ごとに存在する必要があります。また、マテリアライズド・ビュー・ログが必須の場合は、ROWID列が各マテリアライズド・ビュー・ログに存在していること。

- すべてのディテール表のROWIDが、マテリアライズド・ビュー問合せ定義のSELECT構文のリストにあること。

これらの制限で満たされないものがある場合は、マテリアライズド・ビューをREFRESH FORCEとして作成し、可能なときに高速リフレッシュの効果を得ることができます。表がすべての基準を満たさなくても、他の表がすべての基準を満たしている場合は、すべての基準が満たされている他の表に関しては、マテリアライズド・ビューを高速リフレッシュできます。

最適で効率的なリフレッシュを実行する手順は、次のとおりです。

- 定義問合せに内部結合のように動作する外部結合が使用されていないことを確認します。このような結合が定義問合せに含まれている場合は、内部結合を使用するように定義問合せをリライトすることを検討してください。

- マテリアライズド・ビューに含まれているのが結合のみである場合は、各表のROWID列(およびFROM句のリストに複数回指定されている表)を、マテリアライズド・ビューのSELECT構文のリストに指定する必要があります。

- マテリアライズド・ビューのFROM句にリモート表が指定されている場合、そのFROM句の表はすべて同じサイトに配置されている必要があります。また、リモート表を含むマテリアライズド・ビューでは、ON COMMITによるリフレッシュはサポートされません。SCNベースのマテリアライズド・ビュー・ログを除き、マテリアライズド・ビューの各ディテール表のマテリアライズド・ビュー・ログはリモート・サイトに作成されている必要があり、ROWID列は、マテリアライズド・ビューのSELECT構文のリストに指定されている必要があります。

ネステッド・マテリアライズド・ビューのリフレッシュ・オプション

ネステッド・マテリアライズド・ビューとは、その定義が別のマテリアライズド・ビューに基づいているマテリアライズド・ビューです。ネステッド・マテリアライズド・ビューは、マテリアライズド・ビューの他に、データベース内の他のリレーションも参照する場合があります。

データ・ウェアハウスでは、通常、単一の結合上に多数の集計ビュー(たとえば、異なるディメンションに沿ったロールアップ)を作成します。これらの個別の結合と集計を含むマテリアライズド・ビューに対する増分メンテナンスは、ベースとなる結合が何度も実行される必要があるため、かなりの時間がかかります。

ネステッド・マテリアライズド・ビューを使用すると、結合のみを含む1つのマテリアライズド・ビューに基づいて複数の単一表マテリアライズド・ビューを作成できます。さらに、この種類の単一表集計マテリアライズド・ビューには最適化が実行され、リフレッシュが非常に効率的になります。

ネステッド・マテリアライズド・ビューの中には、高速リフレッシュできないタイプがあります。このようなタイプのマテリアライズド・ビューを特定するには、EXPLAIN_MVIEWを使用します。

DBMS_MVIEW.REFRESHパラメータとともにnested =TRUEパラメータを指定すると、適切な依存順序でネステッド・マテリアライズド・ビューのツリーをリフレッシュできます。

例3-2 Oracle Communications Data Modelネステッド・マテリアライズド・ビューのリフレッシュ

たとえば、DBMS_MVIEW.REFRESH ('SUM_SALES_CUST_TIME', nested => TRUE)とコールすると、REFRESHプロシージャによって、まずjoin_sales_cust_timeマテリアライズド・ビューがリフレッシュされ、次にsum_sales_cust_timeマテリアライズド・ビューがリフレッシュされます。

マテリアライズド・ビューに対する索引付けの選択

マテリアライズド・ビューに対して行う最も一般的な操作は、問合せの実行および高速リフレッシュですが、各操作には、異なるパフォーマンス要件があります。

- 問合せの実行では、マテリアライズド・ビュー・キー列のすべてのサブセットがアクセスされる必要があり、これらの列のサブセット上で結合および集計が行われる必要がある場合があります。したがって、最適なパフォーマンスには、各マテリアライズド・ビュー・キー列上に単一列のビットマップ索引を作成します。

- 結合のみを含むマテリアライズド・ビューに高速リフレッシュ・オプションを使用する場合は、ROWIDを含む列上に索引を作成して、リフレッシュ操作のパフォーマンスを向上させます。

- 集計を使用するマテリアライズド・ビューが高速リフレッシュ可能な場合は、CREATE MATERIALIZED VIEW文にUSING NO INDEXが指定されていないかぎり、高速リフレッシュ・プロシージャに適切な索引が作成されます。

関連項目:
「Oracle Communications Data Modelの索引とパーティション索引」

パーティション化とマテリアライズド・ビュー

データ・ウェアハウスに格納されているデータの量は膨大であるため、パーティション化は、データベースの設計時に非常に有効なオプションです。ファクト表のパーティション化によって、スケーラビリティの向上とシステム管理の簡素化を実現できます。また、効率的に再作成できるローカル索引を定義できるようになります。ファクト表をパーティション化することにより、マテリアライズド・ビューに対するパーティション・チェンジ・トラッキング・リフレッシュが可能になるので、マテリアライズド・ビューを高速リフレッシュできる可能性も高くなります。

マテリアライズド・ビューのパーティション化は、ファクト表のパーティション化と同じ利点があります。マテリアライズド・ビューがパーティション化されると、リフレッシュ・プロシージャは、より多くの場合にパラレルDMLを使用でき、パーティション・チェンジ・トラッキング・ベースのリフレッシュは、パーティションの切捨てを使用してマテリアライズド・ビューを効率的にメンテナンスできるようになります。

関連項目:
『Oracle Database VLDBおよびパーティショニング・ガイド』、「Oracle Communications Data Modelのパーティション表」、「Oracle Communications Data Modelの索引とパーティション索引」および「Oracle Communications Data Modelのキューブ・パーティション化戦略の選択」

パーティション・チェンジ・トラッキングの使用

最新の状態かどうかの追跡対象を、マテリアライズド・ビュー全体ではなく、より細かく限定でき、それによるメリットが得られます。特定のディテール表のパーティションによる影響を受けるマテリアライズド・ビュー内の行を識別する機能は、パーティション・チェンジ・トラッキングと呼ばれます。1つ以上のディテール表がパーティション化されている場合は、マテリアライズド・ビュー内で、変更されたディテール・パーティションに対応する特定の行を識別できます。これらの行はパーティションが変更されると失効しますが、他のすべての行は最新のままです。

パーティション・チェンジ・トラッキングを使用すると、特定のパーティションに対応するマテリアライズド・ビューの行を識別できます。パーティション・チェンジ・トラッキングは、ディテール表に対するパーティション・メンテナンス操作後の高速リフレッシュのサポートにも使用されます。たとえば、ディテール表のパーティションが切り捨てられるか削除されると、マテリアライズド・ビュー内で影響を受ける行が識別され、削除されます。QUERY_REWRITE_INTEGRITY = ENFORCEDまたはTRUSTEDモードのときは、マテリアライズド・ビュー全体を失効とみなすのではなく、マテリアライズド・ビューの行のうち最新のものと失効しているものが識別され、リフレッシュされる行をクエリー・リライトで使用できるようになります。

DBA_MVIEW_DETAIL_PARTITIONなどの一部のビューでは、どのパーティションが失効しているかまたは最新なのかが具体的に示されます。マテリアライズド・ビューに結合依存の式があることによって、変更対象の表のパーティション・チェンジ・トラッキングが使用可能になる場合は、部分的に失効しているマテリアライズド・ビューへのリライトは行われません。

パーティション・チェンジ・トラッキングをサポートするには、マテリアライズド・ビューが次の要件を満たしている必要があります。

- マテリアライズド・ビューで参照される1つ以上のディテール表が、パーティション化されている必要があります。

- パーティション表には、レンジ、リストまたはコンポジットのいずれかのパーティション化を使用する必要があります。

- 最上位レベルのパーティション・キーは、単一列のみで構成する必要があります。

- マテリアライズド・ビューには、ディテール表のパーティション・キー列、パーティション・マーカー、ROWIDまたは結合依存の式のいずれかを含める必要があります。

- GROUP BY句を使用する場合は、パーティション・キー列、パーティション・マーカー、ROWIDまたは結合依存の式をGROUP BY句に指定する必要があります。

- 分析ウィンドウ関数またはMODEL句を使用する場合は、パーティション・キー列、パーティション・マーカー、ROWIDまたは結合依存の式を、それぞれのPARTITION BY副次句に指定する必要があります。

- データ修正の発生が可能なのは、パーティション表のみです。マテリアライズド・ビューに結合依存の式を含む表に対してパーティション・チェンジ・トラッキング・リフレッシュを実行する際は、いずれの結合依存の表についても、データ修正が発生しないようにしてください。

- COMPATIBILITY初期化パラメータは9.0.0.0.0以上に設定する必要があります。

- パーティション・チェンジ・トラッキングは、ビュー、リモート表または外部結合を参照するマテリアライズド・ビューのためにサポートされていません。

マテリアライズド・ビューの圧縮

マテリアライズド・ビューのデータ圧縮を使用すると、大幅にパフォーマンスが向上します。

冗長性の高いデータ(多数の外部キーを持つ表など)を使用するときは、データ圧縮を考慮します。特に、この候補は、ROLLUP句を使用して作成したマテリアライズド・ビューです。

関連項目:
「Oracle Communications Data Modelのデータ圧縮」および「Oracle Communications Data Modelの集計表」

4 ETLの実装およびカスタマイズ

この章では、Oracle Communications Data Modelウェアハウスを移入するために使用するETL(抽出、変換およびロード)プログラムについて説明します。内容は次のとおりです。

- Oracle Communications Data ModelのETLのロール

- Oracle Communications Data Modelウェアハウスの基盤レイヤーのETL

- Oracle Communications Data ModelのIntra-ETLのカスタマイズ

- Oracle Communications Data Modelウェアハウスの初期ロードの実行

- Oracle Communications Data Modelウェアハウスのデータのリフレッシュ

- Oracle Communications Data ModelのIntra-ETL実行中のエラーの管理

Oracle Communications Data ModelのETLのロール

図2-1「Oracle Communications Data Modelウェアハウスのレイヤー」は、Oracle Communications Data Modelウェアハウスの3つのレイヤー、オプションのステージング・レイヤー、基盤レイヤーおよびアクセス・レイヤーを示しています。図4-1に示すように、2つのタイプのETL(抽出、変換およびロード)を使用して、これらのレイヤーを移入します。

- Source-ETL。ステージング・レイヤー(存在する場合)および基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、ソースETLと呼ばれます。
Oracle Communications Data Modelは、Source-ETLスクリプトを含みません。Oracle Communications Data Modelのアプリケーション・アダプタを使用しないかぎり、ユーザーは、OLTPシステムの知識およびカスタマイズしたOracle Communications Data Modelを使用して、Source-ETLを作成する必要があります。Source-ETLの作成の詳細は、「Oracle Communications Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。

- Intra-ETL。基盤レイヤーのデータを使用してアクセス・レイヤー(つまり、導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)を移入するETLは、Intra-ETLと呼ばれます。
Oracle Communications Data Modelは、Intra-ETLを含みます。デフォルトのIntra-ETLを変更して、カスタマイズした基盤レイヤーからカスタマイズしたアクセス・レイヤーに移入できます。Intra-ETLの詳細は、「Oracle Communications Data ModelのIntra-ETLのカスタマイズ」を参照してください。

図4-1 ETLフロー・ダイアグラム

「図4-1 ETLフロー・ダイアグラム」の説明

Oracle Communications Data Modelウェアハウスの基盤レイヤーのETL

Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、Source-ETLと呼ばれます。

次の方法で、Oracle Communications Data Modelウェアハウスの基盤レイヤーを移入できます。

- Oracle Communications Data Modelウェアハウスの基盤レイヤーを移入するシステムに対してOracle Communications Data Modelのアプリケーション・アダプタを使用できる場合、このアダプタを使用して基盤レイヤーを移入できます。詳細は、「アプリケーション・アダプタを使用した基盤レイヤーの移入」を参照してください。

- Oracle Warehouse Builderまたは別のETLツールを使用して固有のSource-ETLスクリプトを書き込み、それらのスクリプトを使用して基盤レイヤーを移入します。詳細は、「固有のSource-ETLの書込み」を参照してください。

アプリケーション・アダプタを使用した基盤レイヤーの移入

OLTPシステムを移入するアプリケーションに対してOracle Communications Data Modelのアプリケーション・アダプタを使用できる場合、このアダプタを使用してOracle Communications Data Modelウェアハウスの基盤レイヤーを移入します。

たとえば、Oracle Communications Network Charging and ControlシステムのデータからOracle Communications Data Modelウェアハウスの基盤レイヤーを移入する場合、Oracle Communications Data ModelのOracle Communications Network Charging and Controlアダプタを使用できます。詳細は、付録C「Oracle Communications Data ModelのNCCアダプタの使用」を参照してください。

固有のSource-ETLの書込み

Oracle Communications Data Modelのアプリケーション・アダプタを使用していない場合、Oracle Warehouse Builder、別のETLツールまたはマッピング・ツールを使用して、固有のSource-ETLスクリプトを書き込む必要があります。

関連項目:
『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』

Oracle By Example:
Oracle Warehouse Builder:の詳細は、次のOBEチュートリアルを参照してください。

- 「Oracle Warehouse Builder 11gリリース2環境の設定」

- 「Oracle Warehouse Builder 11g R2の強化されたユーザー・インタフェース、ユーザビリティおよび生産性」

- 「ソースおよびターゲット演算子によるデータ変換演算子の使用」

- 「プラッガブル・マッピングの使用」

- 「Database 11gリリース2によるデータ・プロファイリングを使用したソース・データの調査」

チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

次のトピックでは、Source-ETLの書込みの一般的な情報について説明します。

- Source-ETLの設計上の考慮事項

- Oracle Communications Data ModelのSource-ETLのETLアーキテクチャ

- Source-ETLのソースとターゲット・マッピング・ドキュメントの作成

- Source-ETLのデータ品質問題を解決する計画の設計

- Source-ETLワークフローおよびジョブ制御の設計

- Source-ETL例外処理の設計

- 効率的にロードするSource-ETLの書込み

Source-ETLの設計上の考慮事項

Oracle Communications Data ModelのSource-ETLを設計および作成するときは、次の点に注意してください。

- Oracle Communications Data Modelで提供され、『Oracle Communications Data Modelリファレンス』で説明されているカレンダ移入スクリプトを使用してカレンダ・データを移入できます。

- 表は次の順序で移入します。

1. 検索表

2. 参照表

3. 実表

- 1つのカテゴリの表を分析してから、次のカテゴリの表をロードします(たとえば、検索表をロードする前に参照表を分析します)。また、Intra-ETLプロセスを実行する前に、Source-ETLでロードされたすべての表を分析する必要があります。

参照:
『Oracle Database管理者ガイド』の表、索引およびクラスタの分析に関するトピック。

Oracle Communications Data ModelのSource-ETLのETLアーキテクチャ

ETLは、最初に元のソースからデータを抽出し、データの品質を確認して、元のソースのデータを一貫性のある状態にします。ETLは、問合せツール、レポート・ライター、ダッシュボードなどでデータにアクセスするため、物理オブジェクトに「クリーンな」データを移入します。

データの取得が行われる基本サービスは、次のとおりです。

- データ・ソーシング

- データ移動

- データ変換

- データのロード

論理アーキテクチャの観点から、データ取得サービスを提供するためにこれらの構築ブロックを構成する多くの異なる方法があります。データ・ウェアハウス・アーキテクチャ内を対象とする幅広いオプションを含む使用できる主要なアーキテクチャ・スタイルは、次のとおりです。

- バッチ抽出、変換およびロードとバッチ抽出、ロード、変換、ロード
バッチ抽出、変換およびロード(ETL)およびバッチ抽出、ロード、変換、ロード(ELTL)は、データ・ウェアハウス実装の従来のアーキテクチャです。これらの違いは、変換がデータベースの内部または外部で発生するかどうかです。

- バッチ・ハイブリッド抽出、変換、ロード、変換、ロード
バッチ・ハイブリッド抽出、変換、ロード、変換、ロード(ETLTL)は、ハイブリッド戦略です。この戦略は、変換設計に対するハンド・コーディング・アプローチを排除してメタデータドリブン・アプローチを適用する最も高い柔軟性を提供し、エンタープライズ・ウェアハウスのデータ処理機能を引き続き利用できます。このターゲットの設計では、ステージング表をロードする前の事前処理の手順として、変換処理がウェアハウスの外部で最初に実行され、サーゲット表に最後にロードする前に追加の変換処理がデータ・ウェアハウスの内部で実行されます。

- リアルタイム抽出、変換、ロード
最新のデータのサービス・レベルでデータ・ウェアハウス環境の詳細な更新情報を要求する場合、リアルタイム抽出、変換、ロード(rETL)が適切です。このアプローチでは、rETLプロセスが適宜メッセージ・バス(キュー)から抽出するため、OLTPシステムで任意のイベントをアクティブに公開する必要があります。メッセージ・ベース・パラダイムは、公開およびサブスクライブ・メッセージ・バス構造または信頼性のあるキューのポイントツーポイント・メッセージングとともに使用します。

Oracle Communications Data ModelのSource-ETLを設計する場合、ビジネス・ニーズを最適に満たすアーキテクチャを使用します。

Source-ETLのソースとターゲット・マッピング・ドキュメントの作成

抽出システムの構築を開始する前に、表の元のソース・フィールドとターゲット宛先フィールドのリレーションシップをマップする論理データ・インタフェース・ドキュメントを作成します。このドキュメントは、ETLシステムの最初から最後まで適用されます。

データ・マッピング・ドキュメントの列は、結合される場合があります。たとえば、ソース・データベース、表名および列名が単一のターゲット列に結合される場合があります。連結された列内の情報は、ピリオドで区切られます。形式に関係なく、論理データ・マッピング・ドキュメントの内容がETLプロセスの十分な計画に必要となる重要な要素であることが証明されました。

Source-ETLのデータ品質問題を解決する計画の設計

データ・クリーニングは、表に提供するデータを消去および検証し、データを一貫性のある状態にする既知のビジネス・ルールを適用するために必要なすべての手順で構成されます。クリーニングおよび準拠の手順の視点は、データの利点の可能性というよりも包含および制御になります。

データ品質の問題がある場合、問題の解決方法について、ITおよびビジネス・ユーザーとともに計画を構築します。

次の質問に回答します。

- データが見つかりませんか。

- データは不正ですか、またはデータに一貫性がありませんか。

- 問題をソース・システムで修正する必要がありますか。

- データ品質レポート、アクション・プログラムおよび人の責任を設定します。

次のプロセスおよびプログラムを設定します。

- データ品質測定プロセスを設定します。

- データ品質レポート、アクション・プログラムおよび人の責任を設定します。

Source-ETLワークフローおよびジョブ制御の設計

ETLプロセス間のすべてのデータ移動は、ジョブで構成されます。ETLワークフローは、必要な依存性について、適切な順序でこれらのジョブを実行します。Oracle Warehouse Builderなどの一般的なETLツールは、このようなワークフロー、ジョブ設計および実行制御をサポートします。

ETLジョブおよびワークフローを設計する場合のヒントは、次のとおりです。

- すべてのジョブで一般的な構造を使用します(ソース・システム、トランスフォーマ、ターゲット・データ・ウェアハウス)。

- ソースからターゲットの1対1のマッピングを使用します。

- ソース表ごとに1つのジョブを定義します。

- 汎用ジョブ構造およびテンプレート・ジョブを適用して、迅速な開発および一貫性を考慮します。

- 最適化されたジョブ設計を使用して、データ量に基づいてOracleロード・パフォーマンスを利用します。

- パラメータ化されたジョブを設計して、ジョブのパフォーマンスおよび動作の高度な制御を考慮します。

- ジョブのパラレル実行を最大化します。

Source-ETL例外処理の設計

使用しているETLツールまたは開発したマッピング・スクリプトは、ステータスおよびエラー処理表を生成します。

一般的な原則として、すべてのETLがステータスおよびエラーを表に記録します。ETLツールを使用するか、ログ表に直接問い合せて、実行ステータスを監視します。

効率的にロードするSource-ETLの書込み

マッピング・スクリプトを開発してステージング・レイヤーにロードするか、基盤レイヤーに直接ロードするかに関係なく、最も効率的な方法でデータをウェアハウスに格納することが目標です。ロード中の優れたパフォーマンスを実現するには、ロードするデータの場所およびデータベースにロードする方法から開始する必要があります。たとえば、シリアル・データベース・リンクまたは単一のJDBC接続を使用して、大量のデータを移動しないようにする必要があります。大量のデータをロードする最も一般的な推奨メカニズムは、フラット・ファイルからのロードです。

次のトピックでは、効率的なSource-ETLロードを保証するベスト・プラクティスについて説明します。

- フラット・ファイルのステージング領域の使用

- Source-ETLのRAWデータ・ファイルの準備

- Source-ETLデータ・ロード・オプション

- パラレル・ダイレクト・パス・ロードSource-ETL

- Oracle Communications Data ModelのSource-ETLのパーティション交換ロード

フラット・ファイルのステージング領域の使用

データ・ウェアハウス・システムのステージング・レイヤーにロードされる前にフラット・ファイルが格納される領域は、一般的にステージング領域と呼ばれます。ロードの全体の速度は、次の要素で決定されます。

- ステージング領域からRAWデータを読み取ることができる速度。

- RAWデータを処理してデータベースに挿入できる速度。

推奨: ステージング領域の使用

生データはできるだけ多くの物理ディスクにステージングし、生データの読取りがロード時のボトルネックにならないようにします。

また、Exadata Database Machineを使用している場合、データをステージングする最適な場所は、Exadataストレージ・セルに格納されているOracle Database File System(DBFS)内です。DBFSは、データベースに格納されたファイルへのアクセスに使用できるマウント可能なクラスタ・ファイル・システムを作成します。Database Machineの別のデータベースにDBFSを作成します。これにより、データ・ウェアハウスとは別にDBFSを管理および保守できます。

DIRECT_IOオプションを使用してファイル・システムをマウントし、ファイル・システムのRAWデータ・ファイルの移動中のシステム・ページ・キャッシュのスラッシングを回避します。

参照:
DBFSの設定の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

Source-ETLのRAWデータ・ファイルの準備

データ・ロードをパラレル化するには、OracleデータベースでRAWデータ・ファイルをグラニュルと呼ばれるチャンクに論理的に分割できる必要があります。バランスのとれたパラレル処理を保証するため、通常グラニュルの数は、パラレル・サーバー・プロセスの数よりも非常に多くなります。特定の時点で、処理する1つのグラニュルにパラレル・サーバー・プロセスが割り当てられます。パラレル・サーバー・プロセスがグラニュルの処理を完了した後、すべてのグラニュルが処理されてデータがロードされるまで、別のグラニュルが割り当てられます。

推奨: Source-ETLのRAWデータ・ファイルの準備

次の推奨事項に従います。

- 改行やセミコロンなどの認識される文字を使用して、各行を区切ります。これにより、単一のファイル内に複数のグラニュルを作成するためにRAWデータ・ファイル内が参照され、各行のデータの開始場所および終了場所が決定されます。

- ファイルが配置可能および検索可能(たとえば、圧縮ファイル、ZIPファイルなど)ではない場合、ファイルをグラニュルに分割できません。ファイル全体が単一のグラニュルとして処理されます。この場合、1つのパラレル・サーバー・プロセスのみ、ファイル全体で使用できます。圧縮されたデータ・ファイルのロードをパラレル化するには、複数の圧縮されたデータ・ファイルを使用します。使用される圧縮されたデータ・ファイルの数は、ロードで使用される最大の並列度を決定します。

- 複数のデータ・ファイルをロードする場合(圧縮または非圧縮)

- 可能な場合、単一の外部表を使用します。

- ファイルのサイズを同じにします。

- ファイルのサイズを10MBの倍にします。

- 異なるサイズのファイルを使用する必要がある場合、最大から最小までファイルをリストします。デフォルトでは、フラット・ファイルがデータベースと同じキャラクタ・セットであると想定します。該当しない場合、外部表定義のフラット・ファイルのキャラクタ・セットを指定して、適切なキャラクタ・セット変換を実行できることを確認します。

Source-ETLデータ・ロード・オプション

Oracleは、複数のデータ・ロード・オプションを提供します。

- 外部表またはSQL*Loader

- Oracle Data Pump(インポートおよびエクスポート)

- Change Data CaptureおよびTrickleフィード・メカニズム(Oracle GoldenGateなど)

- システムおよびメインフレームを開くOracle Database Gateways

- Generic Connectivity(ODBCおよびJDBC)

実行するアプローチは、受信するデータのソースおよび形式に依存します。

推奨: フラット・ファイルのロード

ファイルからOracleにロードする場合、2つのオプション、SQL*Loaderまたは外部表を使用します。

外部表を使用すると、次の利点があります。

- データベース内の透過的なパラレル化を実行できます。ステージング・データを回避して、外部表にアクセスする場合に任意のSQLまたはPL/SQL構成を使用してファイル・データに直接変換を適用できます。SQL Loaderでは、データをそのままデータベースに最初にロードする必要があります。

- 外部表のロードをパラレル化すると、個々のパラレル・ローダーが固有のトランザクションを使用した個別のデータベース・セッションであるSQL*Loaderよりも効率的な領域管理を実行できます。多くパーティション化した表の場合、多くの未利用領域が発生する可能性があります。

標準のCREATE TABLE文を使用して、外部表を作成できます。ただし、フラット・ファイルからロードするには、データベース外部のフラット・ファイルの場所の情報を文に含める必要があります。外部表からデータをロードする場合の最も一般的なアプローチは、CREATE TABLE AS SELECT (CTAS)文またはINSERT AS SELECT (IAS)文を既存の表に発行することです。

パラレル・ダイレクト・パス・ロードSource-ETL

ダイレクト・パス・ロードは、外部表定義の説明に従って入力データを解析し、各入力フィールドのデータを対応するOracleデータ・タイプに変換して、データの列配列構造を作成します。これらの列配列構造を使用して、Oracleデータ・ブロックをフォーマットし、索引キーを作成します。新しくフォーマットされたデータベース・ブロックはデータベースに直接書き込まれるため、標準SQL処理エンジンおよびデータベース・バッファ・キャッシュが省略されます。

優れたロード・パフォーマンスの秘訣は、可能なかぎりダイレクト・パス・ロードを使用することです。

- CREATE TABLE AS SELECT (CTAS)文は、常にダイレクト・パス・ロードを使用します。

- 単純なINSERT AS SELECT (IAS)文は、ダイレクト・パス・ロードを使用しません。IAS文でダイレクト・パス・ロードを実現するには、APPENDヒントをコマンドに追加する必要があります。

ダイレクト・パス・ロードはパラレルでも実行できます。ダイレクト・パス・ロードの並列度を設定するには、次のいずれかを実行します。

- PARALLELヒントをCTAS文またはIAS文に追加します。

- 外部表およびデータをロードする表にPARALLEL句を設定します。
並列度の設定後:

- CTAS文は、パラレルのダイレクト・パス・ロードを自動的に実行します。

- IAS文は、パラレルのダイレクト・パス・ロードを自動的に実行しません。IAS文でパラレルのダイレクト・パス・ロードを有効にするには、次の文を実行して、セッションを変更してパラレルDMLを有効にする必要があります。

alter session enable parallel DML;

Oracle Communications Data ModelのSource-ETLのパーティション交換ロード

パーティション化の利点は、EXCHANGE PARTITIONコマンドを使用してビジネス・ユーザーの影響を最小限にデータを迅速かつ容易にロードする機能です。EXCHANGE PARTITIONコマンドは、パーティション化されていない表のデータをパーティション化された表の特定のパーティションにスワップできます。EXCHANGE PARTITIONコマンドは物理的にデータを移動しません。かわりに、データ・ディクショナリを更新してパーティションおよび表のポインタを交換します。

データの物理的な移動がないため、交換はREDOおよびUNDOを生成しません。つまり、交換は1秒以内の処理で、INSERTなどの従来のデータ移動アプローチよりもパフォーマンスへの影響が大幅に少なくなります。

推奨: 表のパーティション化

Oracle Communications Data Modelウェアハウスの大きい表およびファクト表をパーティション化します。

例4-1 パーティション表でのパーティション交換文の使用

日単位でレンジ・パーティション化されるSalesという大きい表があるとします。各営業日の最後に、オンライン販売システムのデータがウェアハウスのSales表にロードされます。

次の手順により、日単位のデータがデータ・ウェアハウスのビジネス・ユーザーへの影響を最小限に最適な速度で正しいパーティションにロードされます。

1. オンライン・システムから取得するフラット・ファイル・データの外部表を作成します。

2. CTAS文を使用して、Sales表と同じ列構造を持つtmp_salesというパーティション化されていない表を作成します。

3. tmp_sales表のSales表の索引を作成します。

4. EXCHANGE PARTITIONコマンドを発行します。

Alter table Sales exchange partition p2 with
table top_sales including indexes without validation;

5. 増分統計を使用して、新しく交換したパーティションのオプティマイザ統計を収集します。

この例のEXCHANGE PARTITIONコマンドは、名前が付いたパーティションおよびtmp_sales表の定義をスワップするので、パーティション表の正しい場所にデータがすぐに配置されます。また、INCLUDING INDEXESおよびWITHOUT VALIDATION句を使用すると、索引の定義をスワップし、データが実際にパーティションに属するかどうかを確認しないため、交換が非常に迅速になります。

注意:
この例の想定では、データの整合性がデータ抽出時間に確認されました。データの整合性がわからない場合、データベースでデータの妥当性を確認するため、WITHOUT VALIDATION句を省略します。

Oracle Communications Data ModelのIntra-ETLのカスタマイズ

Oracle Communications Data Modelは、Oracle Warehouse BuilderなどのETLツールの使用をサポートして、Intra-ETLプロセスを実行するワークフローを定義します。固有のIntra-ETLを書き込むことができます。ただし、Intra-ETLコンポーネントは、Oracle Warehouse Builderワークフロー・コンポーネントを使用して設計されたプロセス・フローのOracle Communications Data Modelで提供されます。このプロセス・フローは、INTRA_ETL_FLWと呼ばれます。

図4-1「ETLフロー・ダイアグラム」で示すように、INTRA_ETL_FLWプロセス・フローは、Oracle Communications Data Modelの実表、参照表および検索表のデータを使用して、他のすべてのOracle Communications Data Model構造を移入します。このパッケージ内で、各プログラムを適切な順序で実行するため、個々のプログラムの依存性が実装および適用されます。

特定の要件の元のIntra-ETLスクリプトを変更できます。ただし、変更を行う前に完全な影響分析を実行します。元のOracle Communications Data Model Intra-ETLマッピングのパッチとして、変更をパッケージ化します。

INTRA_ETL_FLWプロセス・フローは、次のサブプロセスから構成され、個々のサブプロセス・フローの依存関係を含み、それらを適切な順序で実行します。

1. DRVD_FLW
このサブプロセス・フローには、実表、参照表および検索表の内容に基づいて導出表を移入するためのすべてのOracle Warehouse Builderマッピングが含まれます。このプロセス・フローにより、マッピングを同時に実行できます。

このサブプロセスは、次のテクノロジを使用します。

- MERGE句。この文は、初期ロードおよび増分ロードに使用します。ターゲット表に挿入または更新されるデータが受信データによるキー列の確認に基づいているかを識別し、INSERTおよびUPDATEの組合せと比較して非常に優れたパフォーマンスを提供します。

- TABLEファンクション。このファンクションは、個別のステージング表の必要性を回避するため、導出表(およびソース・データ)に主に使用します。ステージング表がないと、ETL操作のパフォーマンスが向上し、データベースのメンテナンスが容易になります。

- パイプライン句。この句は、作成した直後に追加処理用に段階的に結果セットを戻すためにTABLEファンクションで使用します。そのため、この句の使用で大量の戻りが回避され、完全なプロセスが通常の戻りよりも高速になります。

2. AGGR_FLW
このサブプロセス・フローには、パーティション変更追跡計画を使用してOracle Communications Data Model内のマテリアライズド・ビューであるすべての集計表をリフレッシュするPL/SQLコードが含まれます。

このサブプロセスは、次のテクノロジを使用します。

- マテリアライズド・ビュー。マテリアライズド・ビューを使用して、集計データを保持します。リフレッシュされるたびに、変更されたデータが対応する集計表に反映され、問合せ実行パフォーマンスが大幅に向上します。また、マテリアライズド・ビューを使用すると、Oracle Communications Data Modelは優れたSQL最適化のためにOracleクエリー・リライト機能を使用して、パフォーマンスを向上できます。

- 高速リフレッシュ。このリフレッシュ・タイプを使用して、直前のリフレッシュの後に実表および導出表の増分データ(挿入および変更)のみの集計をリフレッシュし、この増分リフレッシュがさらに優れたパフォーマンスを実現するため、Intra-ETL期間が短くなります。

3. MINING_FLW
このサブプロセス・フローは、データ・マイニング・モデルのリフレッシュをトリガーします。

INTRA_ETL_FLWプロセス・フローには、OLAP_MAPマッピングも含まれます。OLAP_MAPは、PKG_OCDM_OLAP_ETL_AW_LOADパッケージの分析ワークスペース構築機能を呼び出して、Oracle Communications Data Modelの集計マテリアライズド・ビューからOracle Communications Data Model分析ワークスペースにデータをロードし、予測データを計算します。PKG_OCDM_OLAP_ETL_AW_LOADパッケージは、OLAP ETLパラメータをocdm_sysスキーマ内のDWC_OLAP_ETL_PARAMETER制御表から読み取って、データのロード方法と予測の実行方法の詳細を判断します。

注意:
Oracle Communications Data Modelで提供されるシェル・スクリプトocdm_execute_wf.shは、Oracle Warehouse Builder Workflow INTRA_ETL_FLWと同じファンクションを実行します。このシェル・スクリプトは、Oracle Warehouse Builderワークフローを必要としません。このスクリプトの操作の詳細は、「ocdm_execute_wf.sh Scriptの手動実行」を参照してください。

参照:
Oracle Communications Data Model Intra-ETLの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

Oracle Communications Data Modelウェアハウスの初期ロードの実行

Oracle Communications Data Modelの初期ロードの実行は、複数ステップのプロセスです。

1. 「基盤レイヤーの初期ロードの実行」の説明に従って、Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)をロードします。

2. 「アクセス・レイヤーの初期ロードの実行」の説明に従って、Oracle Communications Data Modelウェアハウスのアクセス・レイヤー(つまり、導出表および集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)をロードします。

基盤レイヤーの初期ロードの実行

Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)の初期ロードを実行する方法は、Oracle Communications Data Modelのアプリケーション・アダプタを使用しているかどうかによって異なります。

- Oracle Communications Data Modelのアプリケーション・アダプタを使用している場合、このアダプタを使用して基盤レイヤーをロードします。たとえば、「Oracle Communications Data ModelのNCCアダプタを使用した初期ロード」の説明に従って、Oracle Communications Data ModelのNCCアダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤーにOracle Communications Network Charging and Controlシステムのデータを移入できます。

- アプリケーション・アダプタを使用していない場合、作成するSource-ETLを使用して基盤レイヤーの初期ロードを実行します。このETLの作成の詳細は、「固有のSource-ETLの書込み」を参照してください。

アクセス・レイヤーの初期ロードの実行

Oracle Communications Data Modelウェアハウスのアクセス・レイヤー(導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)の初期ロードを実行するには、次の手順に従います。

1. ocdm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新して、この情報(ETL期間の開始日と終了日)を導出と集計の表およびビューのロード時にETLで使用できるようにします。
Oracle Communications Data Modelウェアハウスの初期ロードでは、次の表に示す値を指定します。

列

値

PROCESS_NAME

'OCDM-INTRA-ETL'

FROM_DATE_ETL

ETL期間の開始日。

TO_DATE_ETL

ETL期間の終了日。

参照:
DWC_ETL_PARAMETER制御表の詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

2. ocdm_sysスキーマ内のDWC_OLAP_ETL_PARAMETER制御表のOracle Communications Data Model OLAP ETLパラメータを更新して、構築メソッドおよびその他の構築特性を指定し、この情報をOLAPキューブ・データのロード時にETLで使用できるようにします。
分析ワークスペースの初期ロードの場合は、表4-1のガイドラインに従って値を指定します。

表4-1 初期ロード用のDWC_OLAP_ETL_PARAMETER表のOracle Communications Data Model OLAP ETLパラメータの値

列名

値

PROCESS_NAME

'OCDM-INTRA-ETL'

BUILD_METHOD

C。この値は、ロード前にすべてのディメンション値をクリアする完全リフレッシュを指定します。

CUBENAME

構築するキューブを指定する次の値のいずれか。

- ALL: Oracle Communications Data Modelアナリティック・ワークスペースにキューブの作成を指定します。

- cubename[[|cubename]...]は、1つ以上のキューブの作成を指定します。

MAXJOBQUEUES

このジョブに割り当てるパラレル・プロセス数を指定する10進値。(デフォルト値は4。)指定する値は、JOB_QUEUE_PROCESSESデータベース初期化パラメータの設定によって異なります。

CALC_FCST

予測キューブを計算するかどうかに応じて、次のいずれかの値。

- Y: 予測キューブを計算する。

- N: 予測キューブを計算しない。

NO_FCST_YRS

CALC_FCST列の値がYの場合は、計算する予測データの年数を指定する10進値を指定します。それ以外の場合はNULLを指定します。

FCST_MTHD

CALC_FCST列の値がYの場合、AUTOを指定し、それ以外の場合はNULLを指定します。

FCST_ST_YR

CALC_FCST列の値がYの場合は、履歴期間の"開始ビジネス年"であるyyyyを値として指定します。それ以外の場合はNULLを指定します。

FCST_END_YR

CALC_FCST列の値がYの場合は、履歴期間の"終了ビジネス年"であるyyyyを値として指定します。それ以外の場合はNULLを指定します。

OTHER1

NULLを指定します。

OTHER2

NULLを指定します。

3. 「デフォルトのOracle Communications Data ModelのIntra-ETLの実行」で説明している方法の1つを使用して、Intra-ETLを実行します。

関連項目:
「Oracle Communications Data Modelウェアハウスのデータのリフレッシュ」

デフォルトのOracle Communications Data ModelのIntra-ETLの実行

Oracle Communications Data Modelで提供されるIntra-ETLパッケージは、次の方法で実行できます。

- 「Oracle Warehouse BuilderのINTRA_ETL_FLWワークフローの実行」で説明しているように、Oracle Warehouse Builderのワークフローとして実行します。

- 「ocdm_execute_wf.shスクリプトの手動実行」で説明しているように、Oracle Warehouse Builderワークフローを使用しないで実行します。

どちらの場合でも、Intra-ETLを明示的に実行したり、他のプログラムまたはプロセス(たとえば、正常な実行の後のSource-ETLプロセスなど)または事前定義済のスケジュール(たとえば、Oracle Job Scheduling機能の使用など)で実行を起動したりできます。

参照:
「Intra-ETLプロセスの実行の監視」、「Intra ETLプロセスのリカバリ」および「Intra-ETLのパフォーマンスのトラブルシューティング」。

Oracle Warehouse BuilderのINTRA_ETL_FLWワークフローの実行

デプロイ後、Oracle Warehouse Builder内からINTRA_ETL_FLWプロセスを実行できます。

INTRA_ETL_FLWプロセス・フローをデプロイするには、次の手順に従います。

1. 『Oracle Communications Data Modelインストレーション・ガイド』の説明に従ってOracle Warehouse Builderワークフローがインストールされていることを確認します。

2. Oracle Warehouse Builder内で、Control Center Managerに移動します。

3. OLAP_PFLW、AGR_PFLWの順に選択し、メイン・プロセス・フローINTRA_ETL_FLWを選択します。

4. INTRA_ETL_FLWを右クリックして、「アクションの設定」を選択します。

- これが最初のデプロイメントの場合、アクションを「作成」に設定します。

- これが後のデプロイメントの場合、アクションを「置換」に設定します。

プロセス・フローをデプロイします。

デプロイメントが正常に完了すると、INTRA_ETL_FLWの実行準備ができます。

参照:
Oracle Warehouse Builderの詳細は、『Oracle Warehouse Builderソースおよびターゲット・ガイド』を参照してください。

ocdm_execute_wf.shスクリプトの手動実行

Oracle Communications Data Modelには、Oracle Warehouse Builderワークフローを使用せずにIntra-ETLを移入するために使用できるスクリプトが用意されています。このシェル・スクリプトの名前はocdm_execute_wf.shです。

ocdm_execute_wf.shスクリプトは、Oracle Warehouse BuilderワークフローのINTRA_ETL_FLWと同じ機能を実行します。スクリプトは、Source-ETLなどの別のプロセスによって呼び出すか、Oracle Job Schedulingなどの事前定義済スケジュールに従って呼び出すことができます。

1. ocdm_execute_wf.shプログラムは、次の表で説明する環境変数の入力を求めるプロンプトを表示します。

変数

説明

TSNAME

ターゲット・データベースのtnsname。

SYSTEMパスワード

ターゲット・データベースのSYSTEMアカウント・パスワード。

ocdm_sysパスワード

ocdm_sysアカウントのパスワード。

ORACLE HOME

Oracleデータベース・ホーム(/で終了するフルパス)。

2. 適切な順序でマッピングを実行する前に、ocdm_sysスキーマ内のDWC_ETL_PARAMETERおよびDWC_OLAP_ETL_PARAMETER制御表から値を読み取ります。

3. 「Intra-ETLプロセスの実行の監視」で説明するように、各表のロードの結果は、DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITY制御表で追跡されます。

Oracle Communications Data Modelウェアハウスのデータのリフレッシュ

「アクセス・レイヤーの初期ロードの実行」では、Oracle Communications Data Modelデータ・ウェアハウスの初期ロードの実行方法について説明しています。この初期ロードの後に、ビジネス分析を容易にするという目的を満たせるように、Oracle Communications Data Modelデータ・ウェアハウスに新規データを定期的にロードする必要があります。

Oracle Communications Data Modelウェアハウスに新規データをロードするには、1つ以上の業務系システムからデータを抽出し、そのデータをウェアハウスにコピーする必要があります。データ・ウェアハウス環境では、多数のシステムにわたる大量のデータを統合、再配置および連結し、結果として、統一された新たな情報ベースをビジネス・インテリジェンスに提供することが課題になります。

継続的なロードおよび変換は、ビジネス・ニーズによって決定される特定の順序でスケジュールして処理する必要があります。操作または操作の一部が成功したか失敗したかに応じて、結果を追跡する必要があります。また、場合によっては後続の代替プロセスを開始できます。

Oracle Communications Data Modelウェアハウスの完全増分ロードを実行するか、次のようにデータを順次にリフレッシュできます。

1. Oracle Communications Data Modelウェアハウスの基盤レイヤーのリフレッシュ

2. Oracle Communications Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ

どちらの場合でも、「Oracle Communications Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。

Oracle Communications Data Modelウェアハウスの基盤レイヤーのリフレッシュ

次の方法で、Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)をリフレッシュできます。

- Oracle Communications Data Modelウェアハウスの基盤レイヤーをリフレッシュするシステムに対してOracle Communications Data Modelのアプリケーション・アダプタを使用できる場合、このアダプタを使用して基盤レイヤーをリフレッシュできます。
たとえば、「Oracle Communications Data ModelのNCCアダプタを使用したデータのリフレッシュ」の説明に従って、Oracle Communications Data ModelのNCCアダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤーをOracle Communications Network Charging and Controlシステムのデータでリフレッシュできます。

- Oracle Warehouse Builderまたは別のETLツールを使用して書き込まれたSource-ETLスクリプトを使用して、基盤レイヤーをリフレッシュできます。Source-ETLの作成の詳細は、「固有のSource-ETLの書込み」を参照してください。

Oracle Communications Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ

Oracle Communications Data Modelのアクセス・レイヤーのリフレッシュは、複数ステップのプロセスです。アクセス・レイヤーの完全増分ロードを一度に実行するか、次のようにデータを順次にリフレッシュできます。

1. Oracle Communications Data Modelの導出表および集計表のリフレッシュ

2. Oracle Communications Data ModelのOLAPキューブのリフレッシュ

3. Oracle Communications Data Modelデータ・マイニング・モデルのリフレッシュ

どちらの場合でも、「Oracle Communications Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。

Oracle Communications Data Modelの導出表および集計表のリフレッシュ

Oracle Communications Data Modelのリレーショナル表およびビューのリフレッシュは、複数ステップのプロセスです。

1. 書き込まれたSource-ETLを実行して、OLTPデータを使用してOracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)をリフレッシュします。

2. ocdm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新します。Oracle Communications Data Modelウェアハウスの増分ロードの場合は、次の表で示す値を指定します(ETL期間の開始日と終了日)。

列

値

PROCESS_NAME

'OCDM-INTRA-ETL'

FROM_DATE_ETL

ETL期間の開始日。

TO_DATE_ETL

ETL期間の終了日。

参照:
DWC_ETL_PARAMETER制御表の詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

3. INTRA_ETL_FLWプロセス・フローのDRVD_FLOWおよびAGGR_FLOWサブプロセスを実行することで、Oracle Communications Data Modelのマテリアライズド・ビューである導出表と集計表をリフレッシュします。詳細は、「デフォルトのOracle Communications Data ModelのIntra-ETLの実行」を参照してください。

関連項目:
Oracle Warehouse Builderソースおよびターゲット・ガイド

Oracle Communications Data ModelのOLAPキューブのリフレッシュ

スケジュールに基づいて、OLAPキューブの初期ロード以降にOracle Communications Data Modelデータ・ウェアハウスに追加されたリレーショナル・データでOLAPキューブ・データを更新する必要があります。

次の方法で、Oracle Communications Data Model ETLを実行してOLAPキューブを更新できます。

- 「デフォルトのOracle Communications Data ModelのIntra-ETLの実行」で説明されているいずれかの方法で、Oracle Warehouse Builder Workflow INTRA_ETL_FLWを実行することでウェアハウス内のすべてのデータをリフレッシュします。
OLAPキューブは、Oracle Communications Data Model Intra-ETLのメイン・ワークフローINTRA_ETL_FLWの一部であるOLAP_MAPを介して移入されます。

- Oracle Warehouse Builderコントロール・センターでOLAP_MAP Oracle Warehouse Builderマッピングを実行することにより、OLAPキューブ・データのみリフレッシュします。

注意:
OLAP_MAPを実行する前にリフレッシュしているOLAPキューブの対応するマテリアライズド・ビューをリフレッシュする必要があります。OLAPキューブとマテリアライズド・ビュー間のマッピングは、『Oracle Communications Data Modelリファレンス』を参照してください。

次の手順に従って、Oracle Communications Data Modelウェアハウスの一部である分析ワークスペースの増分ロードを実行します。

1. Oracle Communications Data Modelのマテリアライズド・ビューである集計表を更新します。詳細は、「Oracle Communications Data Modelの導出表および集計表のリフレッシュ」を参照してください。

2. 「デフォルトのOracle Communications Data ModelのIntra-ETLの実行」で説明している方法の1つを使用して、Intra-ETLを実行してキューブ・データをロードします。

3. 必要に応じて、OLAP_MAPの実行中のエラーからリカバリするには、次の手順に従います。

1. ocdm_sys.DWC_OLAP_ETL_PARAMETER表のBUILD_METHOD列の値を"C"に変更します。

2. Oracle Warehouse Builderで、OLAP_MAPマップを再実行します。

Oracle Communications Data Modelデータ・マイニング・モデルのリフレッシュ

INTRA_ETL_FLWプロセス・フローのMINING_FLWサブプロセス・フローは、データ・マイニング・モデルのリフレッシュをトリガーします。ウェアハウスの初期ロード後に、データ・マイニング・モデルを毎月リフレッシュすることをお薦めします。データ・モデルのリフレッシュは、MINING_FLWサブプロセス・フローに統合されています。データ・モデルを手動でリフレッシュすることもできます。

データ・マイニング・モデルをリフレッシュする方法は、すべてのモデルまたは1つのモデルのみをリフレッシュするかどうかによって異なります。

- すべてのマイニング・モデルを手動でリフレッシュするには、次のプロシージャをコールします。

ocdm_mining.PKG_ocdm_mining.REFRESH_MODEL( MONTH_CODE,P_PROCESS_NO)

このプロシージャは、各モデルで次のタスクを実行します。

1. ocdm_sysスキーマの最新データに基づいてマイニング・ソース・マテリアライズド・ビューをリフレッシュします。

2. 新しいトレーニング・データで各モデルをトレーニングします。

3. 各モデルを新しい適用対象データ・セットに適用します。

- 1つのマイニング・モデルのみ手動で再作成するには、対応するプロシージャをコールします。たとえば、チャーンSVMモデルを再作成するには、次のプロシージャをコールできます。

ocdm_mining.create_churn_svm_model( MONTH_CODE );

「チュートリアル: チャーン予測モデルのカスタマイズ」に、単一のデータ・マイニング・モデルをリフレッシュする詳細な手順を示します。

関連項目:
「データ・マイニング・モデルの作成のトラブルシューティング」

Oracle Communications Data ModelのIntra-ETL実行中のエラーの管理

このトピックでは、Intra-ETL実行中のエラーを識別および管理する方法について説明します。内容は次のとおりです。

- Intra-ETLプロセスの実行の監視

- Intra ETLプロセスのリカバリ

- Intra-ETLのパフォーマンスのトラブルシューティング

Intra-ETLプロセスの実行の監視

Intra-ETLプロセスの実行は、2つのocdm_sysスキーマ制御表DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITYによって監視されます。これらの表については、『Oracle Communications Data Modelリファレンス』に記載されています。

個別のIntra-ETL実行の(エラー・リカバリ実行ではなく)通常の各実行では、次のステップが実行されます。

1. 単調に増加するシステム生成の一意のプロセス・キー、プロセス開始時刻としてのSYSDATE、プロセス・ステータスとしてのRUNNING、およびFROM_DATE_ETL列とTO_DATE_ETL列の入力日範囲で、DWC_INTRA_ETL_PROCESS表にレコードを挿入します。

2. 適切な依存性の順序で各Intra-ETLプログラムが起動されます。各プログラムの起動前に、プロシージャは、次の値を使用してレコードをintra-ETLアクティビティ・ディテール表DWC_INTRA_ETL_ACTIVITYに挿入します。

- システムで生成される一意のアクティビティ・キーのACTIVITY_KEY。

- Intra-ETLプロセスに対応するプロセス・キー値のPROCESS_KEY。

- 個々のプログラム名のACTIVITY_NAME。

- 適切なアクティビティの説明のACTIVITY_DESC。

- SYSDATEの値のACTIVITY_START_TIME。

- RUNNINGの値のACTIVITY_STATUS。

3. 個々のETLプログラムが(正常にまたはエラーを戻して)完了するたびに、DWC_INTRA_ETL_ACTIVITY表内の対応するレコードのアクティビティ終了時間およびアクティビティ・ステータスが更新されます。アクティビティが正常に完了した場合、プロシージャはステータスを'COMPLETED-SUCCESS'として更新します。エラーが発生した場合、プロシージャはアクティビティ・ステータスを'COMPLETED-ERROR'として更新し、ERROR_DTL列の対応するエラー詳細も更新します。

4. すべての個々のIntra-ETLプログラムが完了した後、DWC_INTRA_ETL_ PROCESS 表内のプロセスに対応するレコードのプロセス終了時間およびステータスが更新されます。すべての個々のプログラムが成功すると、プロシージャは'COMPLETED-SUCCESS'にステータスを更新し、それ以外の場合は'COMPLETED-ERROR'にステータスを更新します。

最大プロセス・キーに対応するDWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITY表の内容を表示することで、現在のプロセス進行状況、個々のプログラムに要した時間、完了プロセスなど、Intra-ETLの実行状態を監視できます。監視は、Intra-ETLプロシージャの実行中および実行後に行うことができます。

Intra ETLプロセスのリカバリ

Intra-ETLプロセスをリカバリする手順は、次のとおりです。

1. DWC_INTRA_ETL_ACTIVITY表の個々のプログラムに対して追跡されているエラー詳細を参照することでエラーを識別します。

2. エラーの原因を修正します。

3. Intra-ETLプロセスを再起動します。

INTRA_ETL_FLWプロセスは、DWC_INTRA_ETL_ACTIVITY表を参照することで通常の実行かリカバリ実行かを識別します。リカバリ実行中は、INTRA_ETL_FLWは必要なプログラムのみ実行します。たとえば、前回の実行の一部として導出移入エラーが発生した場合、このリカバリ実行は、前回の実行でエラーを生成した個々の導出移入プログラムを実行します。正常完了後に、集計移入プログラムとマテリアライズド・ビューのリフレッシュが適切な順序で実行されます。

このように、Intra-ETLエラー・リカバリはほとんど透過的であり、データ・ウェアハウス管理者またはETL管理者は関与しません。管理者は、エラーの原因を修正して、Intra-ETLプロセスを再起動するだけです。Intra-ETLプロセスが、エラーを生成したプログラムを識別して実行します。

Intra-ETLのパフォーマンスのトラブルシューティング

Intra-ETLのパフォーマンスをトラブルシューティングする手順は、次のとおりです。

- 「実行計画のチェック」の説明に従って、実行計画をチェックします。

- 「PARALLEL DML実行の監視」の説明に従って、パラレルDML実行を監視します。

- 「データ・マイニング・モデルの作成のトラブルシューティング」の説明に従ってデータ・マイニング・モデルが正しく作成されていることを確認します。

実行計画のチェック

SQLDeveloperまたはその他のツールを使用して、Oracle Warehouse Builderで生成されたコードのパッケージ本体を表示します。

たとえば、マップを調べるには、次の手順に従います。

1. コード・ビューアからメインの問合せ文をコピーします。
"CURSOR "AGGREGATOR_c" IS …."から、別の"CURSOR "AGGREGATOR_c$1" IS"のすぐ上にある問合せの終了までコピーします。

2. SQLDeveloperワークシートで、次の文を発行してパラレルDMLをオンにします。

Alter session enable parallel dml;

3. メインの問合せ文を別のSQL Developerワークシートに貼り付け、F6をクリックして実行計画を表示します。
実行計画を慎重に調べて、有効な計画に従ってマッピングを実行します。

PARALLEL DML実行の監視

次のSQL文を実行して、実行された"Parallel DML/Query"文をカウントすることで、マッピングをパラレル・モードで実行していることを確認します。

column name format a50
column value format 999,999
SELECT NAME, VALUE
FROM GV$SYSSTAT
WHERE UPPER (NAME) LIKE '%PARALLEL OPERATIONS%'
OR UPPER (NAME) LIKE '%PARALLELIZED%'
OR UPPER (NAME) LIKE '%PX%'
;

マッピングをパラレル・モードで実行する場合は、マッピングが呼び出されるたびに"DML statements parallelized"が1つ増やされます。この増分が表示されない場合は、マッピングが"パラレルDML"として呼び出されていません。

かわりに"queries parallelized"が1つ増やされている場合は、通常、INSERTの内部のSELECT文はパラレル化されていますが、そのINSERT自体はパラレル化されていないことを意味します。

関連項目:
「Oracle Communications Data Modelのパラレル実行」

データ・マイニング・モデルの作成のトラブルシューティング

データ・マイニング・モデルが作成された後で、ocdm_sys.dwc_intra_etl_activity表内のエラー・ログをチェックします。たとえば、次のコードを実行します。

set line 160
col ACTIVITY_NAME format a30
col ACTIVITY_STATUS format a20
col error_dtl format a80
select activity_name, activity_status,  error_dtl from dwc_intra_etl_activity;

すべてのモデルが正常に作成されている場合、activity_statusはすべて"COMPLETED-SUCCESS"になります。特定のステップのactivity_statusが"COMPLETED-ERROR"の場合は、ERROR_DTL列をチェックし、問題を適宜修正します。

次の例で、Oracle Communications Data Modelを操作する場合にERROR_DTLおよびACTIVITY_NAMEで戻される一般的なエラー・メッセージのトラブルシューティング方法を示します。

- 例4-2「Oracle Communications Data ModelのORA-20991エラーのトラブルシューティング」

- 例4-3「メッセージはありません... [言語=ZHS]エラーのトラブルシューティング」

- 例4-4「Oracle Communications Data ModelのORA-40113エラーのトラブルシューティング」

- 例4-5「Oracle Communications Data ModelのORA-40112エラーのトラブルシューティング」

- 例4-6「Oracle Communications Data ModelのORA-11130エラーのトラブルシューティング」

例4-2 Oracle Communications Data ModelのORA-20991エラーのトラブルシューティング

戻されるエラーがORA-20991: メッセージはありません... [言語=ZHS]CURRENT_MONTH_KEYとします。

このエラーは、DWR_BSNS_MO表に十分なデータがない場合に発生することがあります。たとえば、カレンダ・データに2004年から2009年のデータが移入されている場合、2010年についてマイニング・モデルをリフレッシュすると、このエラーが発生することがあります。

このエラーを解決するには、Oracle Communications Data Modelカレンダ・ユーティリティ・スクリプトを再度実行して、カレンダに十分なデータを移入します。次に例を示します。

Execute Calendar_Population.run('2005-01-01',10);

カレンダ移入ユーティリティ・スクリプトの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

例4-3 メッセージはありません... [言語=ZHS]エラーのトラブルシューティング

戻されるエラーがメッセージはありません... [言語=ZHS]とします。

'ZHS'は言語のコードです。関連する言語名は、データベース環境に応じて異なる名前で表示されることがあります。このエラーは、ocdm_sys.DWC_MESSAGE.LANGUAGEに現在の言語用のメッセージが含まれていない場合に発生します。

DWC_MESSAGE表の値をチェックし、必要に応じて、Oracleセッション変数USERENV('lang')で指定されている言語コードに更新します。

例4-4 Oracle Communications Data ModelのORA-40113エラーのトラブルシューティング

戻されるエラーがcreate_churn_svm_modelに対するORA-40113: 個別ターゲット値の数が不足していますとします。

このエラーは、トレーニング・モデルのターゲット列に複数の値が期待されている場合に、1つの値のみ含まれているか、値が含まれていない場合に発生します。

たとえば、churn_svm_modelの場合、ターゲット列は次のとおりです。

ocdm_mining.DMV_CUST_CHRN_SRC_PRD.chrn_ind

このエラーをトラブルシューティングする手順は、次のとおりです。

1. SQL問合せを実行して、この列に十分な値があるかどうかを確認します。
たとえばchurn_svm_modelでは、次の文を発行します。

select chrn_ind, count(*) from DMV_CUST_CHRN_SRC_PRD  group by chrn_ind;

問合せの結果を次に示します。

C   COUNT(*)
- ----------
1       1228
0             4911

2. 次の表をチェックして、顧客の解約率インジケータが正しく設定されていることを確認します。

- ocdm_sys.dwr_cust.chrn_dtには、解約した顧客の値が含まれている必要があります。

- ocdm_sys.dwd_acct_sttstcには、最近6か月間の顧客ごとの適切な値が含まれている必要があります。

3. 次の文を実行して、ocdm_miningスキーマ内のマイニング・ソース・マテリアライズド・ビューをリフレッシュします。

exec pkg_ocdm_mining.refresh_mining_source;

例4-5 Oracle Communications Data ModelのORA-40112エラーのトラブルシューティング

戻されるエラーが"create_ltv_glmr_model"に対するORA-40112: 有効なデータ行数が不足していますとします。

このモデルでは、ターゲット列はocdm_mining.DMV_CUST_LTV_PRDCT_SRC.TOT_PYMT_RVNです。

このエラーをトラブルシューティングする手順は、次のとおりです。

1. 次のSQL文を実行します。

select count(TOT_PYMT_RVN) from DMV_CUST_LTV_PRDCT_SRC;

2. この問合せで返される値が0(ゼロ)より大きく、顧客数と同等であることを確認します。数値が0以下の場合は、「パラレルDML実行の監視」の説明に従って、Oracle Communications Data Model Intra-ETLの実行ステータスを確認してください。

例4-6 Oracle Communications Data ModelのORA-11130エラーのトラブルシューティング

戻されるエラーが"create_sentiment_svm_model"に対するORG-11130: コレクションにデータが見つかりませんとします。

このエラーは、テキスト指向のモデル・トレーニングのソース表ocdm_mining.dm_cust_cmmntに十分なデータがない場合に発生します。

顧客指向分析用のテキストがロードされていることを確認する手順は、次のとおりです。

1. 次のSQL文を発行します。

Select OVRAL_RSLT_CD, count(CUST_COMMENT) from DWB_EVT_PRTY_INTRACN
group by OVRAL_RSLT_CD;

2. 顧客対話表DWB_EVT_PRTY_INTRACNからのテキスト・コメント数をチェックします。

3. 顧客対話表に十分なデータがない場合は、ソース・システムからOracle Communications Data ModelへのETLロジックを確認します。

5 レポートおよび問合せのカスタマイズ

この章では、Oracle Communications Data Modelウェアハウスのデータのレポート、問合せおよびダッシュボードの作成について説明します。内容は次のとおりです。

- Oracle Communications Data Modelのレポート・アプローチ

- Oracle Communications Data Modelサンプル・レポートのカスタマイズ

- 問合せとレポートの作成

- スター・クエリーの最適化

- Oracle Communications Data Modelレポート・パフォーマンスのトラブルシューティング

- As IsおよびAs Was問合せの書込み

- チュートリアル: 新しいOracle Communications Data Modelダッシュボードの作成

- チュートリアル: 新しいOracle Communications Data Modelレポートの作成

Oracle Communications Data Modelのレポート・アプローチ

Oracle Communications Data Modelウェアハウスのデータからレポートを作成する2つの主なアプローチがあります。

リレーショナル・レポート

リレーショナル・レポートでは、スターのディメンションとして機能する参照エンティティ(つまり、DWR_およびDWL_表)とともにスターの中心にファクト・エンティティを使用して、分析レイヤー・エンティティのレポートを作成します。通常、ファクト・エンティティには、導出および集計エンティティ(つまり、DWD_およびDWA_表)が含まれます。ただし、詳細なレポートを生成するため、参照表とともにベース・エンティティ(つまり、DWB_表)を使用する必要がある場合があります。

通常、参照表(つまり、DWR_表)は、ビジネス階層を含むディメンションを表し、各レベルの階層の表を含むスノーフレーク・エンティティの形式で存在します。これにより、異なる精度で構成される複数のサブジェクト・エリアおよびファクト・エンティティの参照エンティティの適切なセットを関連付けることができます。

たとえば、DWR_DAYおよびDWR_BSNS_MO、DWR_BSNS_QTR、DWR_BSNS_YR表を含む表のセットを使用して、DWD_VOI_CALL_DAYなどのDAYレベルのCDR Wirelessエンティティを問い合せることができます。一方で、DWA_VOI_CALL_MOなどのMONTHレベルのCDR Wirelessエンティティの問合せのため、DWR_BSNS_MO、DWR_BSNS_QTR、DWR_BSNS_YRなどの月レベル以上の高度なレベルのスノーフレークを使用する必要があります。

検索表(つまり、DWL_接頭辞を使用する表)は、値のフラット・リストを含む単一のレベルで構成される単純なディメンションを表します。通常、ほとんどのレポート・ツールは、表面的な最上位レベルをディメンションに追加します。これらは、DWL_で始まる個々の表またはまたは様々なコード・タイプを個別のディメンションに分割するDWL_CODE_MASTERのビュー(DWL_という名前)の可能性があります。

OLAPレポート

OLAPレポートでは、ディメンションおよびキューブ(ファクト)ビューに対してSQLを使用して、Oracle OLAPキューブにアクセスします。キューブおよびディメンションは、スター・スキーマ設計を使用して表されます。ディメンション・ビューは、キューブ(またはファクト)ビューの周囲に集団を形成します。ディメンションおよびキューブ・ビューは、_VIEWで終わる名前を使用したリレーショナル・ビューです。通常、レポートで使用されるディメンション・ビューの名前はdimension_hierarchy_VIEWで、キューブ・ビューの名前はcube_VIEWです。

DWR_表に格納されている対応するリレーショナル・ディメンション・エンティティとは異なり、OLAPディメンション・ビューは、レベル列(level_nameとして識別されます)に基づいて論理的にパーティション化されるすべてのレベルの階層を含む全体のディメンションに関連する情報を含みます。同様に、キューブ・ビューは、キューブ定義の一部である個々のディメンションのレベルの様々な組合せに関連するファクトも含みます。また、キューブ・ビューおよびディメンション・ビューの結合は、必要なディメンション・レベル・フィルタとともにディメンション・キーに基づいています。

OLAPビューはスター・スキーマとしてモデル化されますが、Oracle Business Intelligence Suite Enterprise Editionの特別なモデル化技術を必要とするOLAPレポート方法の特定の一意な機能があります。

関連項目:
Oracle BI Enterprise EditionでのOracle OLAP 11gの使用に関するOracle By Exampleチュートリアル。チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

残りのこの章では、Oracle Communications Data Modelレポートの作成方法について説明します。Oracle Communications Data Modelレポートの例は、次を参照してください。

- 「As IsおよびAs Was問合せの書込み」

- 「チュートリアル: 新しいOracle Communications Data Modelダッシュボードの作成」

- 「チュートリアル: 新しいOracle Communications Data Modelレポートの作成」

- 『Oracle Communications Data Modelリファレンス』に記載されているOracle Communications Data Modelで提供されるサンプル・レポート。

Oracle Communications Data Modelサンプル・レポートのカスタマイズ

サンプル・レポートとダッシュボードは、Oracle Communications Data Modelで提供されます。これらのサンプル・レポートは、OLAPやデータ・マイニング機能など、Oracle Communications Data Modelで提供される分析機能を示します。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

サンプル・レポートは、あらゆる分析およびレポート機能を提供するエンタープライズ・ビジネス・インテリジェンス製品の包括的なスイートであるOracle Business Intelligence Suite Enterprise Editionを使用して開発されています。このため、レポートは、Oracle Business Intelligence Suite Enterprise Edition AnswersおよびDashboardプレゼンテーション・ツールを使用して有用なレポートを簡単に作成できることも示します。

Oracle Business Intelligence Suite Enterprise Edition AnswersおよびDashboardプレゼンテーション・ツールを使用して、事前定義済のサンプル・ダッシュボード・レポートをカスタマイズできます。

- Oracle BI Answers。純粋なWebアーキテクチャでエンド・ユーザーに非定型機能を提供します。ユーザーは情報の論理ビューと対話するため、データ構造の複雑さが完全に隠されると同時にランナウェイ問合せが防がれます。ユーザーは、チャート、ピボット・テーブル、レポートおよび視覚に訴えるダッシュボードを簡単に作成できます。

- Oracle BI Interactive Dashboards。ナレッジ・ワーカーに、情報への直感的で対話的なアクセスを提供します。エンド・ユーザーは、レポート、プロンプト、チャート、表、ピボット・テーブル、グラフィックスおよびチケットを操作できます。ダッシュボードで得られた結果は、ドリル操作、ナビゲート、変更、対話が可能です。

参照:
サンプル・レポートの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

問合せとレポートの作成

ocdm_sysスキーマは、Oracle Communications Data Modelのリレーショナル表およびビューを定義します。任意のSQLレポート・ツールを使用して、これらの表およびビューに対する問合せおよびレポートを行うことができます。

Oracle Communications Data Modelでは、ocdm_sysスキーマに定義されているOLAPキューブを使用したオンライン分析処理(OLAP)レポートもサポートされます。SQLツールを使用してキューブに対して定義されているビューを問い合せるか、OLAPツールを使用してOLAPコンポーネントを直接問い合せることで、OLAPキューブの問合せおよびOLAPキューブに関するレポートの作成を行うことができます。

関連項目:
「Oracle Communications Data Modelのレポート・アプローチ」、「Oracle OLAPキューブ・ビュー」および『Oracle OLAPユーザーズ・ガイド』のディメンション・オブジェクトの問合せの説明。

例5-1 Oracle Communications Data Modelのリレーショナル問合せの作成

たとえば、2009年3月のサンフランシスコ地域の上位10位の顧客の合計通話時間(分)を知る必要があるとします。この質問に回答するには、次の表で説明する表を問い合せる必要があります。

エンティティ名

表名

説明

WIRELESS CALL EVENT

DWB_WRLS_CALL_EVT

ワイヤレス・コールの発生数。

CUSTOMER

DWR_CUST

個々の顧客

ADDRESS LOCATION

DWR_ADDR_LOC

住所全体。表には、国、州、都市、住所などのレベルがあります。

GEOGRAPHY CITY

DWR_GEO_CITY

GEOGRAPHY階層のCITYレベル。

この問合せを実行するには、次のSQL文を実行します。

SELECT cust_key, tot_call_min FROM
(select         round(sum(call.call_drtn)/60,2) tot_call_min , call.cust_key
from    DWB_WRLS_CALL_EVT call,
DWR_CUST     cust,
DWR_ADDR_LOC addr,
DWR_GEO_CITY city
Where to_date(to_char(call.evt_begin_dt,'MON-YY'),'MON-YY') like        to_date('MAR-09','MON-YY')
and cust.cust_key = call.cust_key
and cust.addr_loc_key = addr.addr_loc_key
and addr.geo_city_key = city.geo_city_key
and initcap(city.geo_city_name)='San Francisco'
group by call.cust_key
order by 1 desc) WHERE ROWNUM < 10;

この問合せの結果を次に示します。

CUST_KEY TOT_CALL_MIN
---------- ------------
3390        101.6
4304       100.25
4269        97.37
4152        93.02
4230        92.97
4157        92.95
3345        91.62
4115        48.43
4111        44.48

スター・クエリーの最適化

アクセス・レイヤーの通常の問合せは、ファクト表と多数のディメンション表の結合で、一般的にスター・クエリーと呼ばれます。スター・クエリーで、各ディメンション表は、主キーと外部キーの結合を使用してファクト表に結合されます。通常、ディメンション表は相互に結合しません。

通常、このような問合せで、すべてのWHERE句の述語はディメンション表およびファクト表にあります。このタイプの問合せの最適化は非常に容易です。

この問合せを最適化するには、次の操作を実行します。

- ビットマップ索引をファクト表の各外部キー列上に作成します。

- 初期化パラメータSTAR_TRANSFORMATION_ENABLEDをTRUEに設定します。

これにより、デフォルトで下位互換性がオフのスター・クエリーのオプティマイザ機能が有効になります。

使用している環境がこれらの2つの基準を満たすと、スター・クエリーは、スター型変換と呼ばれるSQLをリライトまたは変換する強力な最適化技術を使用します。スター型変換は、2つのフェーズで問合せを実行します。

1. ファクト表(行セット)から必要な行を取得します。

2. この行セットをディメンション表に結合します。

すべての外部キー列のビットマップ索引間のビットマップ結合を使用して、ファクト表の行を取得します。オプティマイザが該当する場合にSTAR_TRANSFORMATIONを自動的に選択するため、エンド・ユーザーはSTAR_TRANSFORMATIONの詳細を把握する必要がありません。

例5-2「スター型変換」に、STAR_TRANSFORMATIONを使用してスター・クエリーを最適化する段階的なプロセスを示します。

例5-2 スター型変換

図3-1「スター・スキーマ・ダイアグラム」のスター・スキーマに対して要求される可能性のあるビジネス上の質問として、「2008年5月中にボストンで販売された傘の総数は何ですか」という質問があります。

1. 元の問合せです。

select SUM(quantity_sold) total_umbrellas_sold_in_Boston
From Sales s, Customers c, Products p, Times t
Where s.cust_id=cust_id
And s.prod_id = p.prod_id
And s.time_id=t.time_id
And c.cust_city='BOSTON'
And p.product='UMBRELLA'
And t.month='MAY'
And t.year=2008;

表示されているとおり、すべてのWHERE句の述語はディメンション表にあり、ファクト表(Sales)が外部キー、主キー・リレーションシップを使用して各ディメンションに結合されます。

2. 次の処置を行います。

1. ビットマップ索引をファクト表の各外部キー列上に作成します。

2. 初期化パラメータSTAR_TRANSFORMATION_ENABLEDをTRUEに設定します。

3. リライトされた問合せです。問合せをリライトおよび転送し、外部キー列のビットマップ索引を使用してファクト表から必要な行のみを取得します。

select SUM(quantity_sold
From Sales
Where cust_id IN
(select c.cust_id From Customers c Where c.cust_city='BOSTON')
And s.prod_id IN
(select p.prod_id From Products p Where  p.product='UMBRELLA')
And s.time_id IN
(select t.time_id From Times(Where t.month='MAY' And tyear=2008);

この方法で問合せをリライトすると、ビットマップ索引の長所を利用できます。ビットマップ索引はデータベース内の集合ベース処理を提供するため、AND、OR、MINUS、COUNTなどの集合演算の様々なファクト方法を使用できます。そのため、time_idのビットマップ索引を使用して、2008年5月の売上に対応するファクト表の行のセットを識別します。ビットマップで、行のセットは、1および0の文字列として実際に表されます。同様のビットマップを傘の売上に対応するファクト表の行に対して取得し、別のビットマップでボストンの売上にアクセスします。この時点で3つのビットマップが存在し、個々のディメンション制約を満たすファクト表の一連の行をそれぞれ表します。3つのビットマップがビットマップAND操作を使用して結合され、この新しく作成された最終的なビットマップを使用して、問合せの評価に必要なファクト表から行を抽出します。

4. リライトされた問合せを使用して、ファクト表からディメンション表に行を結合します。
通常、ディメンション表に戻る結合はハッシュ結合を使用して実行されますが、Oracleオプティマイザはディメンション表のサイズに依存する最も効率的な結合方法を選択します。

次の図は、STAR_TRANSFORMATIONを開始する場合のスター・クエリーの通常の実行計画を示します。実行計画は、予想どおりに表示されない場合があります。Sales表から行を正常に取得した後、顧客表に戻る結合は存在しません。選択リストを詳細に参照すると、Customers表から実際に何も選択されていないことがわかるため、オプティマイザはディメンション表に戻る結合を把握する必要がありません。また、一部の問合せでSTAR_TRANSFORMATIONを開始してもファクト表のすべてのビットマップ索引を使用しない場合があることがわかります。オプティマイザは、ファクト表から必要な行を取得するために必要なビットマップ索引の数を決定します。追加のビットマップ索引が選択性を改善しない場合、オプティマイザはそのビットマップ索引を使用しません。実行計画の除外されたビットマップに対応するディメンション表を確認する唯一の時間は、第2フェーズまたは後戻り結合フェーズの実行中です。

図optquery3.gifの説明

Oracle Communications Data Modelレポート・パフォーマンスのトラブルシューティング

次のアクションを実行して、Oracle Business Intelligence Suite Enterprise Editionを使用して作成されたレポートの生成に関する問題を識別します。

1. (オンライン)Oracle BI Administratorツールで、「管理」、「セキュリティ」、「ユーザー」、「ocdm」の順に選択します。
「ロギング・レベル」の値が7であることを確認します。

2. Oracle Communications Data Modelリポジトリを開き、「管理」、「キャッシュ」の順に選択します。

3. キャッシュ・マネージャ・ウィンドウの右側のペインで、すべてのレコードを選択し、右クリックして「パージ」を選択します。

4. SQLログを使用して、追跡するレポートまたは問合せを実行します。

5. OracleBI\server\Logにある問合せログ・ファイル(NQQuery.log)を開きます。
最後の問合せSQLは、実行したレポートのログです。最後にアクセスしたレポートでエラーが戻される場合、このログの最後にエラーがあります。

次の例は、これらのエラー・メッセージの使用方法を示します。

- 例5-3「Oracle Communications Data Modelレポートのトラブルシューティング」

- 例5-4「レポートのトラブルシューティング: 表がありません」

- 例5-5「レポートのトラブルシューティング: データベースが接続されていない場合」

例5-3 Oracle Communications Data Modelレポートのトラブルシューティング

ログ・ファイルに次のエラーが含まれているとします。

Query Status: Query Failed: [nQSError: 15018] Incorrectly defined logical table source (for fact table Customer Mining) does not contain mapping for [Customer.Cell Phone Number, Customer.Customer Segment Name, Customer.Party Name].

このエラーは、Oracle Business Intelligence Suite Enterprise Editionリポジトリのビジネス・レイヤーに問題がある場合に発生します。

この場合、Customer.Cell Phone Number、Customer.Customer Segment NameおよびCustomer.Party Nameのマッピングを確認する必要があります。

例5-4 レポートのトラブルシューティング: 表がありません

ログ・ファイルに次のエラーが含まれているとします。

Query Status: Query Failed: [encloser: 17001] Oracle Error code: 942, message: ORA-00942: table or view does not exist.

このエラーは、Oracle Business Intelligence Suite Enterprise Editionリポジトリの物理レイヤーに、実際にはデータベースに存在しない表がある場合に発生します。

問題のある表を確認するには、次の手順を実行します。

1. SQL問合せをデータベース環境にコピーします。

2. 問合せを実行します。

存在しない表は、データベース・クライアントによってマークされます。

例5-5 レポートのトラブルシューティング: データベースが接続されていない場合

ログ・ファイルに次のエラーが含まれているとします。

エラー: Query Status: Query Failed: [nQSError: 17001] Oracle Error code: 12545, message: ORA-12545: connect failed because target host or object does not exist.

意味: このエラーは、データベースが接続されていない場合に発生します。

処置: 物理レイヤーとODBC接続の接続情報をチェックして、リポジトリが適切なデータベースに接続していることを確認します。

As IsおよびAs Was問合せの書込み

2つの一般的な問合せ技術は、「As Is」と「As Was」問合せです。

- As Is問合せの特性

- As Was問合せの特性

- 例: Oracle Communications Data ModelのAs IsおよびAs Was問合せ

As Is問合せの特性

As Is問合せは次の特性があります。

- 結果レポートは、発生時のデータを示します。

- サロゲート・キー列(つまり、主キーおよび外部キー列)を使用して、スノーフレーク・ディメンション表も結合されます。

- サロゲート・キー列を使用して、ファクト表がリーフ・レベルでディメンション表と結合します。

- ディメンションの緩やかに変化するデータは対応するファクト・レコードと結合され、個別に表示されます。

- 異なるバージョンで同様の特性を共有する場合、コンポーネントを追加できます。

As Was問合せの特性

As Was問合せ(Point-in-Time分析とも呼ばれます)には、次の特性があります。

- 結果レポートは、特定の時点の固定されたディメンションおよびディメンション階層のデータを示します。

- 分析日に有効なレコードまたはバージョンを選択するPoint-in-Time日付フィルタを適用して、各スノーフレーク表を最初にフィルタします。この構造は、スノーフレークのPoint-in-Timeバージョンと呼ばれます。

- フィルタされたスノーフレークは、自然キーを使用して、フィルタされていないバージョンと結合されます。すべてのスノーフレーク属性は、Point-in-Timeバージョン別名から取得します。結果構造は、コンポジット・スノーフレークと呼ばれます。

- サロゲート・キーの個々のスノーフレークを結合して、コンポジット・ディメンションを形成します。

- サロゲート・キー列を使用して、ファクト表がリーフ・レベルでコンポジット・ディメンション表と結合します。

- Point-in-Timeバージョンは、時間の前後に関係なく同じビジネス・エンティティのすべての他の可能性のあるSCDバージョンに適用されます。この方法の結合により、ディメンションが特定のPoint-in-Timeレコードのみで構成される印象が与えられます。

- 様々なバージョンのすべてのファクト・コンポーネントは、ディメンション内のPoint-in-Time属性の適用によって正しく追加されます。

例: Oracle Communications Data ModelのAs IsおよびAs Was問合せ

「例で使用されるデータ」に基づいて、次の例はAs IsおよびAs Was問合せの特性を示します。

- 例5-6「婚姻区分で分割された収税のAs Is問合せ」

- 例5-7「婚姻区分で分割された収税のAs Was問合せ」

- 例5-8「郡で分割された収税データのAs Is問合せ」

- 例5-9「郡で分割された収税データのAs Was問合せ」

例で使用されるデータ

使用するデータ・ウェアハウスにCustomer表、CountyおよびTaxPaidファクト表があるとします。2011年1月1日の時点で、これらの表に次の値が含まれています。

Customer表

顧客ID

顧客コード

顧客名

性別

婚姻区分

郡ID

郡コード

郡名

...

有効開始日

有効終了日

101

JoD

John Doe

男性

シングル

5001

SV

サニーベール

...

1-Jan-11

31-Dec-99

102

JaD

Jane Doe

女性

シングル

5001

SV

サニーベール

...

1-Jan-11

31-Dec-99

103

JiD

Jim Doe

男性

既婚

5002

CU

クパチーノ

...

1-Jan-11

31-Dec-99

County表

郡ID

郡コード

郡名

人口

...

有効開始日

有効終了日

5001

SV

サニーベール

非常に多い

...

1-Jan-11

31-Dec-99

5002

CU

クパチーノ

多い

...

1-Jan-11

31-Dec-99

TaxPaid表

顧客ID

日

税タイプ

税金

101

1-Jan-11

プロ税

100

102

1-Jan-11

プロ税

100

103

1-Jan-11

プロ税

100

次のイベントが2011年1月に発生したとします。

- 2011年1月20日に、Jane Doeが結婚します。

- 2011年1月29日に、John Doeがサニーベールからクパチーノに転居します。

したがって、次に示すように、2011年2月1日、County表の値は同じですが、CustomerおよびTaxPaid表に新しいデータがあります。

Customer表

顧客ID

顧客コード

顧客名

性別

婚姻区分

郡ID

郡コード

郡名

...

有効開始日

有効終了日

101

JoD

John Doe

男性

シングル

5001

SV

サニーベール

...

1-Jan-11

29-Jan-11

102

JaD

Jane Doe

女性

シングル

5001

SV

サニーベール

...

1-Jan-11

20-Jan-11

103

JiD

Jim Doe

男性

既婚

5002

CU

クパチーノ

...

1-Jan-11

31-Dec-99

104

JaD

Jane Doe

女性

既婚

5001

SV

サニーベール

...

21-Jan-11

31-Dec-99

105

JoD

John Doe

男性

シングル

5002

CD

クパチーノ

...

30-Jan-11

31-Dec-99

County表

郡ID

郡コード

郡名

人口

...

有効開始日

有効終了日

5001

SV

サニーベール

非常に多い

...

1-Jan-11

31-Dec-99

5002

CU

クパチーノ

多い

...

1-Jan-11

31-Dec-99

TaxPaid表

顧客ID

日

税タイプ

税金

101

1-Jan-11

プロ税

100

102

1-Jan-11

プロ税

100

103

1-Jan-11

プロ税

100

105

1-Feb-11

プロ税

100

104

1-Feb-11

プロ税

100

103

1-Feb-11

プロ税

100

例5-6 婚姻区分で分割された収税のAs Is問合せ

「例で使用されるデータ」を前提とし、婚姻区分で分割された収税データを表示するため、次のSQL文でcust_idサロゲート・キーのTaxPaidファクト表とCustomerディメンション表およびcnty_idサロゲート・キーのCustomerとCountyスノーフレークを結合します。

SELECT cust.cust_nm, cust.m_status, SUM(fct.tx)
FROM taxpaid fct, customer cust, county cnty
WHERE fct.cust_id = cust.cust_id
AND cust.cnty_id = cnt.cnt_id
GROUP BY cust.cust_nm, cust.m_status
ORDER BY 1,2,3;

この問合せの結果を次に示します。既婚の婚姻区分を示す行と独身の婚姻区分を示す行のJane Doeの2つの行があります。

顧客名

婚姻区分

税金

Jane Doe

既婚

100

Jane Doe

シングル

100

Jim Doe

既婚

200

John Doe

シングル

200

例5-7 婚姻区分で分割された収税のAs Was問合せ

「例で使用されるデータ」を前提とし、2011年1月15日の分析日を使用して、婚姻区分で分割された収税データを表示する次のSQL文を発行します。

select
cust.cust_nm, cust.m_status, sum(fct.tax)
from
TaxPaid fct,
(
select
cust_act.cust_id, cust_pit.cust_cd, cust_pit.cust_nm,
cust_pit.m_status, cust_pit.gender,
cust_pit.cnty_id, cust_pit.cnty_cd, cust_pit.cnty_nm
from Customer cust_act
inner join (
select
cust_id, cust_cd, cust_nm,
m_status, gender,
cnty_id, cnty_cd, cnty_nm
from Customer cust_all
where to_date('15-JAN-2011', 'DD-MON-YYYY') between eff_from and eff_to
) cust_pit
on (cust_act.cust_cd = cust_pit.cust_cd)
) cust,
(
select
cnty_act.cnty_id, cnty_pit.cnty_cd, cnty_pit.cnty_nm
from County cnty_act
inner join (
select
cnty_id, cnty_cd, cnty_nm
from County cnty_all
where to_date('15-JAN-2011', 'DD-MON-YYYY') between eff_from and eff_to
) cnty_pit
on (cnty_act.cnty_cd = cnty_pit.cnty_cd)
) cnty
where fct.cust_id = cust.cust_id
and cust.cnty_id = cnty.cnty_id
GROUP BY cust.cust_nm, cust.m_status
order by 1,2,3;

この問合せの結果を次に示します。Jane Doeは2011年1月15日(分析日)に独身のため、Jane Doeのすべての税は独身区分とみなされます。

顧客名

婚姻区分

税金

Jane Doe

シングル

200

Jim Doe

既婚

200

John Doe

シングル

200

かわりに、to_dateフレーズに15-JAN-2011ではなく09-FEB-2011を指定することを除いて完全に同じ問合せを発行するとします。Jane Doeは2011年2月9日に結婚しているため、次に示すようにJane Doeのすべての税は婚姻区分とみなされます。

顧客名

婚姻区分

税金

Jane Doe

既婚

200

Jim Doe

既婚

200

John Doe

シングル

200

例5-8 郡で分割された収税データのAs Is問合せ

「例で使用されるデータ」を前提とし、郡で分割された収税データを示す次のSQL文を発行します。

SELECT cust.cust_nm, cnty.cnty_nm, SUM(fct.tax)
FROM TaxPaid fct, customer cust, county cnty
WHERE fct.cust_id = cust.cust_id
AND cust.cnty_id = cnty.cnty_ID
GROUP BY cut.cust_nm, cnty.cnty_nm
ORDER BY 1,2,3;

この問合せの結果を次に示します。John Doeは2つの異なる郡に居住しているため、John Doeに2つの行のデータがあります。

顧客名

郡名

税金

Jane Doe

サニーベール

200

Jim Doe

クパチーノ

200

John Doe

クパチーノ

100

John Doe

サニーベール

100

例5-9 郡で分割された収税データのAs Was問合せ

「例で使用されるデータ」を前提とし、2011年1月15日の分析日を使用して、郡で分割された収税データを表示する次のSQL文を発行します。

select
cust.cust_nm, cnty.cnty_nm, sum(fct.tax)
from
TaxPaid fct,
(
select
cust_act.cust_id, cust_pit.cust_cd, cust_pit.cust_nm,
cust_pit.m_status, cust_pit.gender,
cust_pit.cnty_id, cust_pit.cnty_cd, cust_pit.cnty_nm
from Customer cust_act
inner join (
select
cust_id, cust_cd, cust_nm,
m_status, gender,
cnty_id, cnty_cd, cnty_nm
from Customer cust_all
where to_date('15-JAN-2011', 'DD-MON-YYYY') between eff_from and eff_to
) cust_pit
on (cust_act.cust_cd = cust_pit.cust_cd
) cust,
(
select
cnty_act.cnty_id, cnty_pit.cnty_cd, cnty_pit.cnty_nm
from County cnty_act
inner join (
select
cnty_id, cnty_cd, cnty_nm
from County cnty_all
where to_date('15-JAN-2011', 'DD-MON-YYYY') between eff_from and eff_to
) cnty_pit
on (cnty_act.cnty_cd = cnty_pit.cnty_cd)
) cnty
where fct.cust_id = cust.cust_id
and cust.cnty_id = cnty.cnty_id
GROUP BY cust.cust_nm, cnty.cnty_nm
order by 1,2,3;

この問合せの結果を次に示します。John Doeは分析日の2011年1月15日にサニーベールに居住しているため、John Doeのすべての税はサニーベール郡とみなされます。

顧客名

郡名

税金

Jane Doe

サニーベール

200

Jim Doe

クパチーノ

200

John Doe

サニーベール

200

かわりに、to_dateフレーズに15-JAN-2011ではなく09-FEB-2011を指定することを除いて完全に同じ問合せを発行するとします。John Doeは2011年2月9日にクパチーノに居住していたため、次に示すようにJohn Doeのすべての税はクパチーノとみなされます。

顧客名

郡名

税金

Jane Doe

サニーベール

200

Jim Doe

クパチーノ

200

John Doe

クパチーノ

200

チュートリアル: 新しいOracle Communications Data Modelダッシュボードの作成

このチュートリアルは、Oracle Communications Data Modelで提供されるOracle Business Intelligence Suite Enterprise Editionサンプル・レポートに含まれるOracle Communications Data Model webcatに基づいて新しいダッシュボードを作成する方法について説明します。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

この例では、「中断された呼および失敗した呼」のダッシュボードを作成し、「中断された呼の比率レポート」および「失敗した呼の比率レポート」をこの新しいダッシュボードに配置することを前提とします。

ダッシュボードを作成するには、次の手順を実行します。

1. ブラウザで、http://servername:9704/analyticsのログイン・ページを開きます。servernameは、webcatがインストールされるサーバーです。

2. ocdmのユーザー名でログインして、パスワードを指定します。
次に、「newDashboard」をクリックして、Oracle Business Intelligence Suite Enterprise Editionダッシュボードを作成します。

図dbd1.gifの説明

3. 名前と説明を入力して、「ネットワーク・ヘルス」フォルダに保存します。「OK」をクリックします。
図dbd2.gifの説明

4. 「カタログ」ビューで、ネットワーク・ヘルス分析フォルダを展開します。失敗した呼の比率レポートおよび中断した呼の比率レポートを確認できます。
図dbd3.gifの説明

5. 「カタログ」ビューから右側のパネルに失敗した呼の比率レポートおよび中断した呼の比率レポートをドラッグします。
図dbd4.gifの説明

6. このセクションのレイアウトを変更して、水平または垂直の2つのレポートを編成できます。
図dbd5.gifの説明

ページ名が"Page1"のままなので、変更する必要があります。

7. ページ名を変更するには、次の手順を実行します。

1. ダッシュボードを選択します。
図dbd6.gifの説明

2. 「ダッシュボードのプロパティ」ウィンドウで、「名前の変更」をクリックします。
図dbd7.gifの説明f

3. 名前を"Dropped Call Rate and Failed Call Rate"に変更して、「OK」をクリックします。
図dbd8.gifの説明

8. ダッシュボードの上部の「保存」をクリックします。新しいダッシュボードが表示されます。
図dbd9.gifの説明

Oracle By Example:
ダッシュボードの作成の詳細は、AnalysesおよびDashboards 11gの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

チュートリアル: 新しいOracle Communications Data Modelレポートの作成

このチュートリアルは、Oracle Communications Data Modelで提供されるOracle Business Intelligence Suite Enterprise Editionサンプル・レポートに含まれるOracle Communications Data Model webcatに基づいて新しいレポートを作成する方法について説明します。

参照:
サンプル・レポートのインストールおよびBusiness Intelligence Suite Enterprise EditionインスタンスのOracle Communications Data ModelのRPDおよびwebcatのデプロイの詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

この例では、「中断された呼と失敗した呼」のレポートを作成して、1つのレポートに中断された呼の比率と失敗した呼の比率を配置することを前提とします。

この新しいレポートを作成するには、次の手順を実行します。

1. ブラウザで、http://servername:9704/analyticsのログイン・ページを開きます。servernameは、webcatがインストールされるサーバーです。

2. ocdmのユーザー名でログインして、パスワードを指定します。
次に、「newAnalysis」をクリックして、Oracle Business Intelligence Suite Enterprise Editionレポートを作成します。

図rpt1.gifの説明

3. 「サブジェクト・エリア」、「ODWT」の順に選択して、リレーショナル・レポートを作成します。
図rpt2.gifの説明

4. ディメンションおよびファクト列を「列の選択」パネルにドラッグして配置します。
図rpt3.gifの説明

5. 「結果」タブを選択してレポートを表示します。
図rpt4.gifの説明

6. 「新規ビュー」をクリックして、チャートをレポートに追加します。
図rpt5.gifの説明

7. 「保存」をクリックして、このレポートをネットワーク・ヘルス分析フォルダに保存します。
図rpt6.gifの説明

Oracle By Example:
レポートの作成の詳細は、AnalysesおよびDashboards 11gの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

A Oracle Communications Data Modelウェアハウスのサイズ設定および構成

この付録では、Oracle Communications Data Modelウェアハウスのサイズ調整および構成について説明します。内容は次のとおりです。

- Oracle Communications Data Modelウェアハウスのサイズ設定

- Oracle Communications Data Modelのバランスのとれたシステムの構成

Oracle Communications Data Modelウェアハウスのサイズ設定

企業は、より迅速により多くの情報を求め、エンタープライズ・データ・ウェアハウス(EDW)から常に拡大する一連のユーザーおよびアプリケーションに至るまで分析を行っています。この需要の増加に対応していくため、EDWはほぼリアルタイムで高可用性を実現する必要があります。データ・ウェアハウスの設計または実装に関係なく、優れたパフォーマンスの最初の秘訣は、使用するハードウェア構成にあります。これは、市場のデータ・ウェアハウス・アプライアンスの数の最近の増加から何よりも明白です。

ただし、このようなシステムのサイズ設定はどうすればよいでしょうか。システムに必要なスループット量および構成の個々のCPUまたはコアで実行できるスループット量を最初に理解する必要があるため、最優先の課題は、データ・ウェアハウスのデータベース領域要件を計算することです。

データ・ウェアハウス環境には、2つのデータ量の見積もりリソースがあります。

- ソース・システムからの見積もられたRAWデータの抽出。この見積もりは、ETLシステム構成およびデータ・ウェアハウス・システムのステージ・レイヤー・データベース領域に影響します。この値は一意のOLTPシステムによって決定されるため、ユーザーがこの情報を計算する必要があります。

- デフォルトのOracle Communications Data Modelスキーマで定義されるオブジェクトをサポートするために格納されるデータに必要な領域。この付録では、この計算を行うために使用できる情報について説明します。

Oracle Communications Data Modelウェアハウスのデータ量の計算を行う場合の計算要素

データ量の計算を行う場合、次の計算要素を検討します。

- 異なるタイプのデータ単位量を計算します。

- 参照表および検索表のデータ。このデータが永久に格納されると想定します。

- 実表のデータ(トランザクション・データ)。このデータがライフ・サイクル内で格納されると想定します。

- スター・スキーマ(導出およびサマリー)。このデータがライフ・サイクル内で格納されると想定します。

- 各タイプのデータの保持を計算します。

- 各タイプの表を保持する月数または年数を定義します。

- データの増加を計算します。

- 年間成長率がトランザクションおよび参照データとスター・スキーマのデータに適用されると想定します。

- 年間変更率が参照データにのみ適用されると想定します。

- 提案された場合、ステージング領域のデータ要件を計算します。

ヒント:
日単位のETLボリュームを問題解決およびソース・システムからの新しい抽出による変換の再実行のために用意された日数で乗算します。

- 索引、一時表およびトランザクション・ログのデータ量を計算します。

- キューブやデータ・マイニングなどのビジネス・インテリジェンス・ツールの領域要件を計算します。

- REDOログおよびOracle ASM領域要件を検討します。

- RAIDアーキテクチャ[RAID 1、0+1、5]を検討します。

- バックアップ戦略を検討します。

- 該当する場合、圧縮要素を検討します。

- OSおよびファイル・システムのディスク領域要件を検討します。

Oracle Communications Data Modelウェアハウスの最小ディスク領域要件を決定する式

Oracle Communications Data Modelウェアハウスの最小ディスク領域要件を決定するため、「Oracle Communications Data Modelウェアハウスのデータ量の計算を行う場合の計算要素」に概説された要素に基づいて、次の式を使用します。

ディスク領域の最小要件 = RAWデータ・サイズ * データベース領域要素 * (1+GrthperY)nY*OSおよびファイル・システム要素 * 圧縮要素 * ストレージ冗長要素

説明:

- RAWデータ・サイズ = (年ごとの参照および検索データ + 年ごとの実/トランザクション・データ + 年ごとの導出およびサマリー・データ +ステージング・データ +他のデータ(OLAP/データ・マイニング))

- データベース領域要素 = 索引 + 一時表 + ログ]

- GrthperY = 年ごとの成長率

- OSおよびファイル・システム要素は、OSとデータベースのインストール、構成および保持領域です。

- 冗長要素= ASMディスク領域およびRAID要素。[ RAID 1=2、RAID 5=1.25または1.33 ]

- 圧縮要素は、圧縮機能の適用方法に依存します。Exadata Databaseマシンで実行している場合、圧縮を使用するとディスク領域が大幅に節約されます。

Oracle Communications Data Modelのバランスのとれたシステムの構成

多くのデータ・ウェアハウス操作は、大規模な表スキャンおよび大量のランダムI/Oを実行する他のI/O集中型操作に基づいています。最適なパフォーマンスを達成するため、ハードウェア構成のサイズをエンド・ツー・エンドで設定して、このレベルのスループットを維持する必要があります。このタイプのハードウェア構成は、バランスのとれたシステムと呼ばれます。バランスのとれたシステムでは、CPUからディスクに至るまでのすべてのコンポーネントをまとめて編成して、利用可能な最大のI/Oスループットを保証します。データ・ウェアハウスの設計者および管理者は、I/Oのパフォーマンスを常に考慮します。データ・ウェアハウスにおける典型的なワークロードとして特にあげられるのは、I/Oの集中です。I/Oの集中は、大量のデータ・ロード、索引の構築、マテリアライズド・ビューの作成、大量のデータに対する問合せなどの操作で発生します。データ・ウェアハウスの基礎となるI/Oシステムを設計して、これらの厳しい要件を満たします。

バランスのとれたシステムを作成するには、次の質問に回答します。

- どれだけのCPUが必要ですか。どれだけの速度が必要ですか。

- どれだけのメモリーが必要ですか。データ・ウェアハウスには、重要なOLTPアプリケーションと同じメモリー要件はありませんか。

- どれだけのI/Oバンド幅コンポーネントが必要ですか。どれだけのI/O速度が必要ですか。

各コンポーネントにはバランスのよくとれたI/Oシステムにするために十分なI/Oバンド幅が提供される必要があります。

次のトピックでは、Oracle Communications Data Modelのバランスのとれたステムの構成について説明します。

- Oracle Communications Data Modelウェアハウスの高いスループットの維持

- 容量ではなくバンド幅のOracle Communications Data ModelのI/Oの構成

- Oracle Communications Data Modelの拡張計画

- ウェアハウスを作成する前のI/Oシステムのテスト

- Oracle Communications Data Modelのバランスのとれたハードウェア構成のガイドライン

Oracle Communications Data Modelウェアハウスの高いスループットの維持

データのサイズが大規模であるため、データ・ウェアハウスに必要とされるハードウェア構成とデータ・スループットは一意です。データ・ウェアハウスのハードウェア構成のサイズ設定を開始する前に、最も高いスループット要件を見積もり、現在または提案済のハードウェア構成で必要なパフォーマンスを提供できるかどうかを決定します。スループットを見積もる場合、次の基準を使用します。

- ピーク時に問合せによりアクセスされるデータ量および許容できるレスポンス時間。

- 一定期間内にロードされるデータ量。

容量ではなくバンド幅のOracle Communications Data ModelのI/Oの構成

計算されたデータ量と最も高いスループット要件に基づいて、時間単位でバックエンドETLプロセスおよびフロント・エンド・ビジネス・インテリジェンス・アプリケーションとともにI/Oスループットを見積もることができます。通常、コアごとのI/Oスループットの秒単位の約200MBの値は、バランスのとれたシステムを設計するための適切な計画値です。I/Oパスのすべての後続の重要なコンポーネント、ホスト・バス・アダプタ、ファイバ・チャネル接続、スイッチ、コントローラおよびディスクのサイズを適切に設定する必要があります。

Oracle Real Application Cluster(Oracle RAC)のデータ・ウェアハウスを実行する場合、I/Oサブシステムのスループットと同じように慎重にクラスタ・インターコネクトのサイズを設定することは重要です。

データ・ウェアハウスのストレージ・サブシステムを構成する場合、単純、効率的、高可用性およびスケーラブルにする必要があります。これを達成する簡単な方法は、S.A.M.E(Stripe and Mirror Everything)方法を適用することです。S.A.M.Eは、ハードウェア・レベルまたはOracle ASM(Automatic Storage Management)の使用あるいは両方の組合せで実装できます。I/Oシステムのサイズ設定に関する変数は数多くありますが、基本的な経験則として、データ・ウェアハウス・システムでパフォーマンスを最適化するには、CPUごとに複数のディスク(各CPUに少なくとも2台のディスク)が必要というルールがあります。

Oracle Communications Data Modelの拡張計画

データ・ウェアハウスの設計者は、データ・ウェアハウスの将来的な拡張を考慮して計画を立てます。システムの拡張に対応するためのアプローチは複数ありますが、特に考慮する必要があるのは、I/O帯域幅を損うことなくI/Oシステムを拡張できるようにすることです。たとえば、20台のディスクで構成された既存のシステムに4台のディスクを追加し、4台の新しいディスクのみにわたってストライプ化された表領域を追加しても、データベースを拡張できません。より適切な解決策は、24台のディスクすべてにわたってストライプ化された表領域を新たに追加し、20台のディスクにストライプ化された既存の表領域を、24台のディスクすべてにストライプ化されるように徐々に変換していくことです。

ウェアハウスを作成する前のI/Oシステムのテスト

新しいシステムにデータ・ウェアハウスを構築する際は、すべてのデータベース・データ・ファイルを作成する前にI/O帯域幅をテストして、必要なI/Oレベルを達成できるかどうかを調べます。ほとんどのオペレーティング・システムでは、サイズの大きいテスト・ファイルの読取り/書込みパフォーマンスを計測する単純なスクリプトで、テストを実行できます。

Oracle Communications Data Modelのバランスのとれたハードウェア構成のガイドライン

バランスのとれたハードウェア構成には、次のヒントを参照できます。

- 全体のスループット = コア数 X 100-200MB(チップ・セットに依存)

- 全体のホスト・バス・アダプタ(HBA)のスループット = 全体のコア・スループット

注意:
全体のコア・スループットが1.6GBの場合、4つの4GビットHBAが必要です。

- HBAポートごとに1つのディスク・コントローラを使用します(スループット量を同じにする必要があります)。

- スイッチは、HBAおよびディスク・コントローラの機能が必要です。

- コントローラごとに最大10個の物理ディスクを使用します(つまり、小さいドライブ146または300GBを使用します)。

- コアごとに最小4GBのメモリー(圧縮を使用する場合は8GB)を使用します。

- インターコネクト・バンド幅は、I/Oバンド幅(インフィニバンド)と同じです。

現在、OracleのOracle Database 11gリリース2の業界標準ハードウェアを結合したOracle Database Machine, Exadataおよび高速の様々なデータベース・マシンを作成するOracle Exadata Storage Server Softwareが用意されています。すべてのデータ管理、特にデータ・ウェアハウスに対する完全にスケーラブルで耐障害性のあるパッケージです。

また、顧客によってOracleデータ・ウェアハウスの設計およびデプロイのリスクを回避できる一連のOptimized Warehouse Reference Configurationsもあります。広範囲の現場経験および専門知識を利用して、Oracleおよびハードウェア・パートナは、様々なサイズ、ユーザー集団およびワークロードをサポートできる選択可能なデータ・ウェアハウス参照構成を開発しました。これらの構成は高速で信頼性があり、数十から数千のユーザーをサポートする単一のサーバーおよびクラスタ化されたサーバーで500GBから100TBを超えるサイズを簡単に設定できます。

B Oracle Communications Data Modelのユーザー権限の操作

この付録では、Oracle Communications Data Modelのユーザー権限の管理について説明します。内容は次のとおりです。

- Oracle Communications Data Modelに作成されるアカウント

- Oracle Communications Data Modelのユーザー権限を考慮する必要がある場合

- サンプル・レポートのユーザーへのSELECT権限のみの付与

Oracle Communications Data Modelに作成されるアカウント

Oracle Communications Data Modelコンポーネントをインストールすると、ocdm_sysおよびocdm_miningという2つのアカウントが作成されます。Oracle Communications Data Modelサンプル・レポートをインストールすると、ocdm_sampleアカウントが作成されます。『Oracle Communications Data Modelインストレーション・ガイド』に記載されているインストール後の手順に従って、新しいパスワードを使用してこれらのアカウントがロック解除されていることを確認します。

参照:
Oracle Communications Data Modelのインストールおよびocdm_sysアカウントとocdm_miningアカウントのロック解除の詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

ocdm_sysアカウントとocdm_miningアカウントは目的が異なります。

- ocdm_sysは、Oracle Communications Data Modelのメイン・スキーマです。このスキーマには、Oracle Communications Data Modelのすべてのリレーショナル・コンポーネントとOLAPコンポーネントが含まれます。
Oracle Communications Data Modelデータ・マイニングの結果表もこのスキーマに含まれます。データ・マイニング・モデルからの最終出力は、他のコンポーネントとの統合を簡単にするためにocdm_sysスキーマに保存されます。ocdm_sysスキーマ内のマイニング結果表で、顧客はリレーショナル・コンテンツをマイニング結果と結合するレポートをはるかに簡単に実行できます。たとえば、顧客はCustomer Segmentationモデルに従って、特定のセグメントに属する顧客の収益合計を問い合せることができます。

- ocdm_miningは、Oracle Communications Data Modelのデータ・マイニング・スキーマです。このスキーマには、最終結果表を除くOracle Communications Data Modelのすべてのマイニング・コンポーネントが含まれます。

Oracle Communications Data Modelのユーザー権限を考慮する必要がある場合

インストール・プロセスにより、両方のアカウントのユーザーに必要な権限が付与されます。製品のインストール後は、次の状況でのみユーザー権限を考慮する必要があります。

- ocdm_miningスキーマは、ocdm_sysスキーマ内の少量の表(つまり、Oracle Communications Data Modelに付属のデータ・モデルの結果の保持に使用される表のみ)に対するSELECT権限のみ必要とします。ocdm_sysスキーマのより多くの表へのアクセスを必要とする追加のデータ・マイニング・モデルを作成する場合は、SELECT権限を明示的に付与します。

- Intra-ETLプログラムは、ocdm_sysスキーマの内部で実行されるため、そのスキーマへの完全なアクセスを必要とします。デフォルトでは、Oracle Communications Data ModelのOracle Warehouse Builder Intra-ETLマッピングはIntra-ETLを実行するためにocdm_sysスキーマに接続します。

- デフォルトでは、Oracle Communications Data Modelサンプル・レポートはocdm_sysスキーマに直接接続します。セキュリティ上の理由から、「サンプル・レポートのユーザーへのSELECT権限のみの付与」に記載された手順に従ってサンプル・レポートのユーザーにSELECT権限のみ付与することが必要な場合があります。

サンプル・レポートのユーザーへのSELECT権限のみの付与

サンプル・レポートのユーザーにSELECT権限のみを付与するには、次の手順に従います。

1. 専用のレポート・ユーザー(OCDM_Reportなど)を作成します。

2. OCDM_Reportのレポートに必要なすべてのOracle Communications Data Model表に対するSELECT権限を付与します。(これらの表にSELECT権限を付与する最も簡単な方法は、DWA_、DWB_、DWD_、DWR_またはDWL_の接頭辞から始まるすべてのOracle Communications Data Model表に付与することです。)

3. OCDM_Reportスキーマに、ocdm_sys表を指すビュー(またはシノニム)を作成します。

4. Oracle Communications Data ModelのOracle Business Intelligence Suite Enterprise Editionリポジトリで、新規スキーマを指すように接続情報を変更します。

C Oracle Communications Data ModelのNCCアダプタの使用

この付録では、Oracle Communications Data ModelのNCCアダプタを使用してOracle Communications Data Modelウェアハウスを移入する情報について説明します。

内容は次のとおりです。

- Oracle Communications Data ModelのNCCアダプタの概要

- Oracle Communications Data ModelのNCCアダプタを使用したウェアハウスの移入

- Oracle Communications Data ModelのNCCアダプタの実行フロー

- Oracle Communications Data ModelのNCCアダプタのコンポーネント

- NCCアダプタによって入力されるOracle Communications Data Modelの表および列

Oracle Communications Data ModelのNCCアダプタのインストールおよび構成の詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

Oracle Communications Data ModelのNCCアダプタに関連付けられたオブジェクトおよびETLの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

Oracle Communications Data ModelのNCCアダプタの概要

Oracle Communications Data ModelのOracle Communications Network Charging and Controlアダプタ(Oracle Communications Data ModelのNCCアダプタとも呼ばれます)は、Oracle Communications Data Modelのオプションです。Oracle Communications Data ModelのNCCアダプタを使用して、Oacle Communications Network Charging and Control(NCC)システムのデータでOracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、実表、参照表および検索表)を移入できます。

Oracle Communications Data ModelのNCCアダプタは、次のコンポーネントを使用します。

- Oracle Communications Data ModelのNCCアダプタで使用されるデータベース・スキーマ

- Oracle Data Integrator

- Oracle GoldenGate

Oracle Communications Data ModelのNCCアダプタで使用されるデータベース・スキーマ

Oracle Communications Data ModelのNCCアダプタは、次のデータベース・スキーマを使用します。

- ソース・スキーマ Oracle Communications Data ModelのNCCアダプタのソースは、NCC BEおよびCSSスキーマで定義されるNCCシステムです。
特定のソース・オブジェクトは、「NCCソース・スキーマ・オブジェクト」で説明します。

- ステージング・レイヤー・スキーマOracle Communications Data ModelのNCCアダプタは、NCCシステムからOracle Communications Data Modelウェアハウスの基盤レイヤー・オブジェクトにデータをロードする場合にステージング領域を使用します。このステージング領域は、変更済データおよび履歴データ格納のために使用され、Oracle Communications Data Modelの基盤レイヤー・オブジェクトをロードする場合にソース・スキーマとして使用されます。Oracle Communications Data ModelのNCCアダプタは、ncc_stgというデータベース・スキーマとしてステージングを定義します。
ncc_stgスキーマは、「ncc_stgスキーマ・オブジェクト」で説明します。

- ターゲット・スキーマOracle Communications Data ModelのNCCアダプタのターゲットは、Oracle Communications Data Modelウェアハウスです。特定のターゲット・オブジェクトは、Oracle Communications Data Modelの基盤レイヤー・オブジェクトです。これらのオブジェクトは、Oracle Communications Data Modelで提供されるocdm_sysスキーマで定義され、『Oracle Communications Data Modelリファレンス』に示されています。
Oracle Communications Data ModelのNCCアダプタは、ocdm_sysスキーマの追加プロシージャを定義します。これらのプロシージャは、「ocdm_sysスキーマに追加される定義」に記載されています。

Oracle Data Integrator

Oracle Communications Data ModelのNCCアダプタは、Oracle Communications Data Modelの基盤レイヤー・オブジェクト(つまり、実表、参照表および検索表)の初期ロードを実行するETLとして、Oracle Data Integrator(ODI)で作成されたETLを使用します。また、ODI ETLを使用して、ステージング・データベースのスケジュール・リフレッシュも実行できます。

Oracle Communications Data ModelのNCCアダプタのODIの使用の詳細は、次のトピックを参照してください。

- 「Oracle Communications Data ModelのNCCアダプタを使用した初期ロード」

- 「ODIのみによるアダプタを使用した場合の実行フロー」

- 「リアルタイム・データによる基盤レイヤーのリフレッシュ」

- 「NCC_OCDMプロジェクト」

Oracle GoldenGate

ODIを使用したOracle Communications Data Modelの基盤レイヤー・オブジェクトの初期ロードを実行した後、Oracle GoldenGateを使用してステージング・データベースに対するNCCソース・データのリアルタイム・フィードを実行できます。

Oracle Communications Data ModelのNCCアダプタのOracle GoldenGateの使用の詳細は、次のトピックを参照してください。

- 「リアルタイム・データによる基盤レイヤーのリフレッシュ」

- 「アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー」

Oracle Communications Data ModelのNCCアダプタを使用したウェアハウスの移入

Oracle Communications Data ModelのNCCアダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、ocdm_sysスキーマで定義された実表、参照表および検索表)を移入またはリフレッシュできます。詳細は、次を参照してください:

- Oracle Communications Data ModelのNCCアダプタを使用した初期ロード

- Oracle Communications Data ModelのNCCアダプタを使用したデータのリフレッシュ

Oracle Communications Data ModelのNCCアダプタを使用して基盤レイヤーを移入した後、基盤レイヤーを移入するためにOracle Communications Data Modelのアプリケーション・アダプタを使用していない場合、同じようにOracle Communications Data Modelのアクセス・レイヤー(つまり、ocdm_sysスキーマで定義された導出表、集計表、OLAPキューブおよびデータ・マイニング・モデル)を移入またはリフレッシュします。詳細は、「アクセス・レイヤーの初期ロードの実行」および「Oracle Communications Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ」を参照してください。

Oracle Communications Data ModelのNCCアダプタを使用した初期ロード

Oracle Communications Data ModelのNCCアダプタを使用してOracle Communications Data Modelウェアハウスの基盤レイヤーの初期ロードを実行するには、Oracle Data Integrator(ODI)を使用して、次の手順に従います。

1. インストールおよび構成で「Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

参照:
ODIで使用するOracle Communications Data ModelのNCCアダプタのインストールおよび構成の手順は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

2. ODI Studio Designerから、NCC_OCDMプロジェクトに移動して、次の手順に従います。

1. 「SRC_STG_NONOGG」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- SRC_STG_LOAD_NON_OGG_PKG

- SRC_STG_EDR_LOAD_INITIAL_PKG

2. 「STG_OCDM」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- STG_OCDM_INITIAL_LOAD_PKG

- STG_OCDM_EDR_PKG

参照:
パッケージの詳細は「NCC_OCDMプロジェクト」、初期ロードの実行フローの説明は「ODIのみによるアダプタを使用した場合の実行フロー」を参照してください。

Oracle Communications Data ModelのNCCアダプタを使用したデータのリフレッシュ

Oracle Communications Data Modelウェアハウスの初期データ・ロードを実行した後、データをリフレッシュする必要があります。

Oracle Communications Data ModelのNCCアダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤーのデータをリフレッシュします。基盤レイヤーのデータをリフレッシュできる2つの異なる方法があります。

- Oracle Data Interfaceを使用して、ステージング領域およびOracle Communications Data Modelウェアハウスの基盤レイヤーのすべてのデータをリフレッシュします。このタイプのリフレッシュを実行するこの手順は、「スケジュール単位の基盤レイヤーのリフレッシュ」で説明します。このタイプのリフレッシュの実行フローは、「ODIのみによるアダプタを使用した場合の実行フロー」で説明します。

- Oracle GoldenGateを使用してステージング領域にリアルタイム・データを移入し、Oracle Data Interfaceを使用してOracle Communications Data Modelウェアハウスのデータをリフレッシュします。このタイプのリフレッシュを実行するこの手順は、「リアルタイム・データを使用した基盤レイヤーのリフレッシュ」で説明します。このタイプのリフレッシュの実行フローは、「アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー」で説明します。

スケジュール単位の基盤レイヤーのリフレッシュ

Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、実表、参照表および検索表)を移入するためにOracle GoldenGateとともにOracle Communications Data ModelのNCCアダプタを使用していない場合、Oracle Data Integrator(ODI)を使用して、スケジュール単位で基盤レイヤーをリフレッシュします。

ODIのみを使用して基盤レイヤーのデータをリフレッシュするには、次の手順に従います。

1. インストールおよび構成で「Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

参照:
ODIで使用するOracle Communications Data ModelのNCCアダプタのインストールおよび構成の手順は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

2. ODI Studio Designerから、NCC_OCDMプロジェクトに移動して、次の手順に従います。

1. 「SRC_STG_NONOGG」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- SRC_STG_LOAD_NON_OGG_PKG

- SRC_STG_EDR_LOAD_INCREMENTAL_PKG

2. 「STG_OCDM」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- STG_OCDM_INITIAL_LOAD_PKG

- STG_OCDM_EDR_PKG

リアルタイム・データによる基盤レイヤーのリフレッシュ

「Oracle Communications Data ModelのNCCアダプタを使用した初期ロード」の説明に従ってOracle Communications Data Modelウェアハウスの初期ロードを実行した後、リアルタイムでOracle Communications Data Modelウェアハウスの基盤レイヤーのデータをリフレッシュできます。

この方法でOracle Communications Data Modelウェアハウスの基盤レイヤーのデータを確認するには、次の手順に従います。

1. 『Oracle Communications Data Modelインストレーション・ガイド』の説明に従って、Oracle Communications Data ModelのNCCアダプタをインストールして、Oracle GoldenGateおよびOracle Data Integrator(ODI)で使用するために構成します。
インストールおよび構成で「Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

2. GGSCIプロンプトから、info allコマンドを発行して、Oracle Communications Data ModelのNCCアダプタで必要なOracle GoldenGateプロセス(次に記載)が実行されていることを確認します。

ソース・システム・プロセス

ステージング・システム・プロセス

マネージャ・プロセス
抽出プロセス(EXTNCC)

抽出ポンプ・プロセス(EXTPNCC)

マネージャ・プロセス
レプリケート・プロセス(REPNCC)

次のコードは、これらのコマンドを発行した正常な結果を示しています。

GGSCI>  (mypc1)  5> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
EXTRACT    RUNNING  EXTNCC   00:00:00   00:00:02
EXTRACT    RUNNING  EXTPNCC  00:00:00   00:00:06

GGSCI>  (ocdm01)  2> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
REPLICAT   RUNNING  REPNCC   00:00:00   00:03:09

ヒント:
2つのソース・システムがある場合、2つのソース・システムのプロセス・ステータスを確認します。
Oracle GoldenGateプロセスを管理するコマンドは、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

3. ODI Studio Designerから、NCC_OCDMプロジェクトに移動して、次の手順に従います。

1. 「SRC_STG_NONOGG」、「プロシージャ」の順に選択して、「EXEC_ NORMAL_TABLES_PKG」を選択および実行します。

2. 「STG_OCDM」、「パッケージ」の順に選択して、STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGを選択および実行します。

参照:
パッケージの詳細は「NCC_OCDMプロジェクト」、実行フローの説明は「アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー」を参照してください。

Oracle Communications Data ModelのNCCアダプタの実行フロー

Oracle Communications Data ModelのNCCアダプタは、Oracle GoldenGateとともにアダプタを使用しているかどうかによって少し異なる実行フローを使用します。

- アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー

- ODIのみによるアダプタを使用した場合の実行フロー

アダプタ、Oracle GoldenGateおよびODIを使用した場合の実行フロー

「リアルタイム・データによる基盤レイヤーのリフレッシュ」の説明に従って、Oracle GoldenGateとともにOracle Communications Data ModelのNCCアダプタを使用してOracle Communications Data Modelウェアハウスの基盤レイヤーをリフレッシュする場合、基盤レイヤー・データがNCCソース・データと常に同期します。

図C-1に、Oracle GoldenGateでアダプタを使用する場合のOracle Communications Data ModelのNCCアダプタの実行フローを示します。

図C-1 Oracle GoldenGateでアダプタを使用する場合の実行フロー

「図C-1 Oracle GoldenGateでアダプタを使用する場合の実行フロー」の説明

Oracle Communications Data ModelのNCCアダプタとともにOracle GoldenGateを使用する場合、実行フローは次のとおりです。

1. Oracle Communications Data ModelのNCCアダプタのすべてのOracle GoldenGateプロセスが実行モードであると想定すると、新しいデータがソース・データベースに挿入されるたびに、GoldenGateパラメータ・ファイルは新しい受信データを抽出し、それを使用して通常のステージング表に移入します。

2. (図の手順2および3) pre_ocdm_loadプロシージャは、通常のステージング表のデータを使用したステージング領域のデルタ表およびデルタ表のデータを使用したステージング領域のデルタ履歴表を実行およびロードします。

注意:
デルタ履歴表のデータのみ永久に残存し、常にソース・データと同期します。デルタ・ステージング表のデータがOracle Communications Data Modelウェアハウスの基盤レイヤーにロードされると、デルタ表が切り捨てられます。

3. (図の手順4) ODIは、ステージング表のデータが変更されると、ステージング・レイヤーのデルタ表からOracle Communications Data Modelウェアハウスの基盤レイヤーにデータをロードします。

ODIのみによるアダプタを使用した場合の実行フロー

Oracle Data Integrator(ODI)のみでOracle Communications Data ModelのNCCアダプタを使用できます。Oracle Communications Data ModelのNCCアダプタを使用するこの方法は、Oracle Communications Data ModelのNCCアダプタのODIプル・バージョンと呼ばれる場合があります。

「Oracle Communications Data ModelのNCCアダプタを使用した初期ロード」の説明に従ってインストール直後に実行する初期ロードに対して、NCCアダプタのODIプル・バージョンを常に使用します。後で、「スケジュール単位の基盤レイヤーのリフレッシュ」の説明に従って、これを使用してスケジュールされたデータ・リフレッシュを実行することもできます。

図C-2に、ODIのみでアダプタを使用する場合のOracle Communications Data ModelのNCCアダプタの実行フローを示します。

図C-2 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー

「図C-2 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー」の説明

このアプローチを使用する場合、実行プロセスは次のとおりです。

1. (図の手順1および3) アダプタは、ODIを使用して、ソース・データベースからステージ・データベースにデータをロードします。

2. (図の手順2および5) 事前および事後プロシージャを使用して、アダプタは、最終日表、デルタ表、履歴表など、データを複数の表のステージ・データベース表にロードします。

3. (図の手順4) アダプタは、通常の表'MINUS'最終日表を使用して、ステージング領域のデルタ表をロードします。

4. (図の手順6) アダプタは、デルタ表からOracle Communications Data Modelウェアハウスの基盤レイヤーにデータをロードします。

Oracle Communications Data ModelのNCCアダプタのコンポーネント

Oracle Communications Data ModelのNCCアダプタは、次のコンポーネントを使用します。

- NCCソース・スキーマ・オブジェクト

- Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義

- STG_OCDMフォルダ

NCCソース・スキーマ・オブジェクト

Oracle Communications Data ModelのNCCアダプタは、ソース・データとして次のNCC表のデータを使用します。

BE_BALANCE
BE_BUCKET
BE_WALLET
CCS_ACCT
CCS_ACCT_ACCT_REFERENCES
CCS_ACCT_REFERENCE
CCS_ACCT_TYPE
CCS_BALANCE_TYPE
CCS_BALANCE_UNIT
CCS_BE_CDR
CCS_MB_RECHARGE
CCS_VOUCHER_BATCH
CCS_VOUCHER_REFERENCE
CCS_WALLET_TYPE

また、Oracle Communications Data ModelのNCCアダプタは、NCC cssデータベースで定義されるCCS_RECHARGE_TYPEビューを使用します。

Oracle Communications Data ModelのNCCアダプタで追加したスキーマ定義

『Oracle Communications Data Modelインストレーション・ガイド』の説明に従ってOracle Communications Data ModelのNCCアダプタをインストールおよび構成すると、次の定義が追加されます。

- アダプタで使用するステージング領域を定義するncc_stgというデータベース。このデータベースの定義の詳細は、「ncc_stgスキーマ・オブジェクト」を参照してください。

- Oracle Communications Data Modelウェアハウスの基盤レイヤーを移入するために使用するプロシージャ定義。これらの定義は、Oracle Communications Data Modelで提供されるocdm_sysスキーマに追加されます。これらのプロシージャの詳細は、「ocdm_sysスキーマに追加される定義」を参照してください。

ncc_stgスキーマ・オブジェクト

ncc_stgスキーマは、Oracle Communications Data ModelのNCCアダプタで使用するステージング領域を定義します。スキーマには、表C-1に記載された定義が含まれます。

表C-1 ncc_stgスキーマの定義

オブジェクト・タイプ

オブジェクト名

説明と使用方法

タイプ

CDR_T

イベント詳細レコード(EDR)データの移入をサポートします。

タイプ

CDRSET_T

EDRデータの移入をサポートします。

表

CCS_BE_CDR

イベント詳細レコード表。

表

source_table_name

通常のステージング表。「NCCソース・スキーマ・オブジェクト」にリストされているNCCソース表ごとに1つの表定義があります。

表

source_table_name_LD

前日表。「NCCソース・スキーマ・オブジェクト」に示されているNCCソース表ごとに1つの表定義があります。

表

source_table_name_DELTA

デルタ表。「NCCソース・スキーマ・オブジェクト」に示されているNCCソース表ごとに1つの表定義があります。

表

source_table_name_DELTA_H

デルタ履歴表。「NCCソース・スキーマ・オブジェクト」に示されているNCCソース表ごとに1つの表定義があります。

ビュー

CCS_RECHARGE_TYPE

これは、ncc_ccsデータベースの同じ名前のビューに対応するステージング領域のビューです。

ビュー

CDR_FREEFORM_RECHARGE

EDRデータの移入をサポートします。

ビュー

CDR_PREPAID

EDRデータの移入をサポートします。

ビュー

CDR_SMS

EDRデータの移入をサポートします。

ビュー

CDR_VOICE_CALL

EDRデータの移入をサポートします。

ビュー

VOUCHER_RECHARGE

EDRデータの移入をサポートします。

ビュー

VOUCHER_RECHARGE_BALANCE_TYPE

EDRデータの移入をサポートします。

パッケージ

EDR

EDRデータの移入をサポートします。

プロシージャ

POST_STAGING_LOAD

毎日のソース・データ変更およびデータ変更の履歴を保守します。Oracle GoldenGateオプションで使用されます。

プロシージャ

PRE_STAGING_LOAD

毎日のソース・データ変更およびデータ変更の履歴を保守します。Oracle GoldenGateオプションで使用されます。

プロシージャ

PRE_OCDM_LOAD

毎日のソース・データ変更およびデータ変更の履歴を保守します。ODIのみのオプションで使用されます。

ocdm_sysスキーマに追加される定義

インストールおよび構成すると、次のプロシージャ定義がOracle Communications Data Modelで提供されるocdm_sysスキーマに追加されます。

DISB_CONS
ENAB_CONS
INSERT_REF
LOOK_UP_LOAD_ONE_TIME
UPDATE_ACCT
UPDATE_CHURN_DATE
UPDATE_CNRT
UPDATE_CUST
UPDATE_PROD
UPDATE_PRPD_VCHR_INSTNC
UPDATE_SBRP

Oracle Communications Data ModelのNCCアダプタは、ターゲット・オブジェクトを移入するため、これらのプロシージャを使用します。

NCC_OCDMプロジェクト

Oracle Communications Data ModelのNCCアダプタをインストールおよび構成すると、NCC_OCDMプロジェクトというODIプロジェクトが定義されます。NCC_OCDMプロジェクトには、次のフォルダが含まれます。

- SRC_STG_NONAGGフォルダは、ステージング領域にNCCソース・システムのデータを移入するために使用するパッケージを含みます。

- STG_OCDMフォルダは、Oracle Communications Data Modelウェアハウスの基盤レイヤーにOracle Communications Data ModelのNCCアダプタのステージング領域のデータを移入するために使用するパッケージを含みます。

SRC_STG_NONAGGフォルダ

NCC_OCDMプロジェクトのSTG_STG_MPMAGGフォルダのパッケージを使用して、NCCソース・システムのデータ(つまり、NCC BEおよびCSSデータベースで定義される表)からステージング・レイヤーの表(つまり、ncc_stgデータベースで定義される表)を移入します。

SRC_STG_LOAD_NON_OGG_PKGパッケージ

このパッケージは、NCCソース・データベースからNCCステージング・データベースにデータをロードします。初期ロード中およびODI.のみを使用して基盤レイヤーをリフレッシュする場合に、このパッケージを使用します。

SRC_STG_EDR_LOAD_INCREMENTAL_PKGパッケージ

このパッケージは、NCCソースのイベント詳細レコード増分データをステージング・データベースのEDR表(つまり、CCS_BE_CDR表)にロードします。

SRC_STG_EDR_LOAD_INITIAL_PKGパッケージ

このパッケージは、NCCソースのイベント詳細レコード初期データをステージング・データベースのEDR表(つまり、CCS_BE_CDR)にロードします。基盤レイヤーの初期ロード中に、このパッケージを使用します。

STG_OCDMフォルダ

STG_OCDMフォルダのパッケージを使用して、ステージング領域のデータ(つまり、ncc_stgデータベースで定義される表)からOracle Communications Data Modelウェアハウスの基盤レイヤーの表(つまり、ocdm_sysデータベースで定義される表)に移入します。

次のパッケージは、NCC_OCDMプロジェクトのSTG_OCDMフォルダで定義されます。

- STG_OCDM_INITIAL_LOAD_PKGパッケージ

- STG_OCDM_EDR_PKGパッケージ

- STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージ

STG_OCDM_INITIAL_LOAD_PKGパッケージ

このパッケージは、ステージング領域のデルタ表のデータ(イベント詳細レコード・オブジェクト以外)からOracle Communications Data Modelウェアハウスの基盤レイヤー表にデータをロードします。初期ロード中およびODIのみを使用してデータをリフレッシュする場合に、このパッケージを使用します。このパッケージは、階層順でncc_source_table_MAPというSTG_OCDMフォルダ(ncc_source_tableは「NCCソース・スキーマ・オブジェクト」にリストされているNCCソース表の名前です)のインタフェースを実行します。これらのインタフェースは、ステージング・デルタ表(つまり、ncc_source_table_DELTA表)のデータを使用して、関連する基盤レイヤー表を移入します。

次のインタフェースは、このパッケージで実行されます。

- BE_BALANCE_MAP

- BE_BUCKET_MAP

- CCS_ACCT_ BE_WALLET _MAP

- CCS_ACCT_CNRT_MAP

- CCS_ACCT_REFERENCE_MAP

- CCS_ACCT_SBRP_MAP

- CCS_ACCT_TYPE_MAP

- CCS_BALANCE_TYPE_MAP

- CCS_BALANCE_UNIT_MAP

- CCS_MB_RECHARGE_MAP

- CCS_RECHARGE_TYPE_MAP

- CCS_VOUCHER_BATCH_MAP

- CCS_VOUCHER_REFERENCE_MAP

- CCS_WALLET_TYPE_MAP

STG_OCDM_EDR_PKGパッケージ

このパッケージは、ステージング・レイヤーのイベント詳細レコード・オブジェクトからOracle Communications Data Modelウェアハウスの基盤レイヤーの表をロードします。初期ロード中およびODIのみを使用してデータをリフレッシュする場合に、このパッケージを使用します。

パッケージは、階層順で次のSTG_OCDMイベント詳細レコード・インタフェースを実行します。

- EDR_FREEFROM

- EDR_RECHARGE_BALANCE_TYPE

- EDR_RECHRG

- EDR_CALL_EVT

- EDR_PREPAID

- EDR_SMS

STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージ

STG_OCDMフォルダは、各NCCソース表の1つのパッケージを含みます。これらのパッケージの名前は、ncc_source_table_PKGです。ncc_source_tableは、「NCCソース・スキーマ・オブジェクト」にリストされているNCCソース表の名前です。

これらのパッケージが実行モードの場合、Oracle Communications Data Modelの基盤レイヤー表を移入するインタフェースを実行します。

Oracle GoldenGateを使用してステージング・レイヤーのデータをリフレッシュする場合、これらのパッケージを使用します。

STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGは、最終的に次のインタフェースをコールするSTG_OCDM_OGG_CDC_LOAD_PKGをコールします。

- BE_BALANCE_PKG

- BE_BUCKET_PKG

- CCS_ACCT_ BE_WALLET _PKG

- CCS_ACCT_CNRT_PKG

- CCS_ACCT_REFERENCE_PKG

- CCS_ACCT_SBRP_PKG

- CCS_ACCT_TYPE_PKG

- CCS_BALANCE_TYPE_PKG

- CCS_BALANCE_UNIT_PKG

- CCS_MB_RECHARGE_PKG

- CCS_RECHARGE_TYPE_PKG

- CCS_VOUCHER_BATCH_PKG

- CCS_VOUCHER_REFERENCE_PKG

- CCS_WALLET_TYPE_PKG

NCCアダプタによって入力されるOracle Communications Data Modelの表および列

表C-2に、NCCアダプタによって入力されるOracle Communications Data Modelの表および列を示します。

表C-2 NCCアダプタによって入力されるOracle Communications Data Modelの表および列

ターゲット表

ターゲット列

備考

DWB_ACCT_BAL_BUCKET

BUCKET_CD

DWB_ACCT_BAL_BUCKET

ACCT_BAL_TYP_CD

DWB_ACCT_BAL_BUCKET

NEVER_EXP_IND

DWB_ACCT_BAL_BUCKET

EXP_DT

DWB_ACCT_BAL_BUCKET

BUCKET_AMT

DWB_ACCT_BAL_BUCKET

NEVER_USED_IND

DWB_ACCT_BAL_BUCKET

LAST_USE_DT

DWB_ACCT_BAL_BUCKET

EXTRNL_REF

DWB_ACCT_BAL_BUCKET

STRT_DT

DWB_ACCT_BAL_HIST

ACCT_KEY

ルックアップの実行、acct_cd別のacct_keyの検出

DWB_ACCT_BAL_HIST

ACCT_BAL_TYP_CD

DWB_ACCT_BAL_HIST

MIN_CRDT_AMT

DWL_ACCT_BAL_TYP

ACCT_BAL_TYP_CD

DWL_ACCT_BAL_TYP

ACCT_BAL_TYP_NAME

DWL_ACCT_BAL_TYP

CRNCY_UNIT

DWL_ACCT_BAL_TYP

ACCT_BAL_TYP_DESC

DWL_ACCT_TYP

ACCT_TYP_CD

DWL_ACCT_TYP

ACCT_TYP_DESC

DWL_ACCT_TYP

ACCT_TYP_NAME

NAMEの値とncc_acctの連結

DWL_ACCT_TYP

ACCT_TYP_CD

DWL_ACCT_TYP

LAST_UPDT_DT

DWL_ACCT_TYP

LAST_UPDT_BY

DWL_ACCT_TYP

ACCT_TYP_NAME

DWL_UOM

UNIT_OF_MSR_CD

DWL_UOM

LAST_UPDT_DT

DWL_UOM

LAST_UPDT_BY

DWL_UOM

UNIT_OF_MSR_NAME

DWR_ACCT

ACCT_CD

NCCウォレットおよびprnt_acct_keyの"NCCWL_" || IDは空

DWR_ACCT

STAT_CD

DWR_ACCT

BAL_EXP_PRD

DWR_ACCT

TMNT_DT

DWR_ACCT

INITIAL_ACTVTN_DT, & crt_dt

INITIAL_ACTVTN_DTとcrt_dt両方へのロード

DWR_ACCT

DWR_ACCT

ACCT_Name

DWR_ACCT

LAST_UPDT_DT

DWR_ACCT

LAST_UPDT_BY

DWR_ACCT

CRNCY_CD

DWR_ACCT

ACCT_TYP_CD

DWR_ACCT

LAST_UPDT_DT

DWR_ACCT

LAST_UPDT_BY

DWR_CNRT

ACCt_KEY

DWR_CNRT

CUST_KEY

DWR_CNRT

CNRT_CD

DWR_CNRT

LAST_UPDT_DT

DWR_CNRT

LAST_UPDT_BY

DWR_CNRT

CNRT_CD

"NCCWL_" || IDのロード

DWR_CUST

CUST_CD (同じものをPRTY_CDにロード)

DWR_CUST

CUST_NAME

DWR_CUST

LAST_UPDT_DT

DWR_CUST

LAST_UPDT_BY

DWR_CUST

ソース・システム識別子

DWR_CUST

CRT_DT

DWR_CUST

PRTY_DESC

DWR_CUST

cust_typ_cd

DWR_CUST

Chrn_DT

DWR_PROD

VCHR_CD

単純なproduct_cd

DWR_PROD

LAST_UPDT_DT

DWR_PROD

LAST_UPDT_BY

DWR_PROD

VCHR_DESC & PROD_DESC

DWR_PROD

VCHR_NAME & PROD_NAME

DWR_PROD

PRE_USE_EXPRY_PRD

DWR_PROD

SHORT_NAME

DWR_PROD

ACCT_EXPRY_PRD

DWR_PROD

PROD_TYP_CD

定数値

DWR_PROD

PROD_DESC

DWR_PROD

PROD_CD

DWR_PROD

PROD_NAME

DWR_PRPD_VCHR_BTCH

VCHR_KEY

DWR_PRPD_VCHR_BTCH

ACTVTN_DT

DWR_PRPD_VCHR_BTCH

BTCH_CD

DWR_PRPD_VCHR_BTCH

BTCH_NAME

DWR_PRPD_VCHR_BTCH

LAST_UPDT_DT

DWR_PRPD_VCHR_BTCH

LAST_UPDT_BY

DWR_PRPD_VCHR_BTCH

END_OF_RNG

DWR_PRPD_VCHR_BTCH

ORGNL_CNT

DWR_PRPD_VCHR_BTCH

STRT_OF_RNG

DWR_PRPD_VCHR_BTCH

STATE

DWR_PRPD_VCHR_BTCH

prod_key

DWR_PRPD_VCHR_BTCH

STRT_SRL_NBR

DWR_PRPD_VCHR_BTCH

END_SRL_NBR

DWR_PRPD_VCHR_INSTNC

PROD_INSTNC_CD

プリペイド・バウチャのインスタンス・コード

DWR_PRPD_VCHR_INSTNC

LAST_UPDT_DT

DWR_PRPD_VCHR_INSTNC

LAST_UPDT_BY

DWR_PRPD_VCHR_INSTNC

ISUD_DT

DWR_PRPD_VCHR_INSTNC

USED_DT

DWR_PRPD_VCHR_INSTNC

STAT

DWR_PRPD_VCHR_INSTNC

BTCH_KEY

DWR_PRPD_VCHR_INSTNC

VCHR_NBR

DWR_PRPD_VCHR_INSTNC

VCHR_PIN_NBR

DWR_PRPD_VCHR_INSTNC

prod_key

定数値 - cd="NCC_VOUCHER"に関連付けられたキーを使用

DWR_PRPD_VCHR_RCHRG_OPTN

VCHR_KEY

DWR_PRPD_VCHR_RCHRG_OPTN

LAST_UPDT_DT

DWR_PRPD_VCHR_RCHRG_OPTN

LAST_UPDT_BY

DWR_PRPD_VCHR_RCHRG_OPTN

ACCT_BAL_TYP_CD

DWR_PRPD_VCHR_RCHRG_OPTN

RCHRG_OPTN_CD

DWR_PRPD_VCHR_RCHRG_OPTN

VAL

DWR_PRPD_VCHR_RCHRG_OPTN

BAL_EXPRY_PRD

DWR_PRPD_VCHR_RCHRG_OPTN

STRT_DT

DWR_PRPD_VCHR_RCHRG_OPTN

END_DT

DWR_PRPD_VCHR_RCHRG_OPTN

NEW_BUCKET_IND

DWR_PRPD_VCHR_RCHRG_OPTN

BAL_EXPRY_POLICY

DWR_PRPD_VCHR_RCHRG_OPTN

RPLC_BAL_IND

DWR_PRPD_VCHR_RCHRG_OPTN

VAL_TYP

DWR_PRTY

prty_typ_cd

DWR_SBRP

CNRT_TYP_CD

dwr_prodからのprod_keyのルックアップ

DWR_SBRP

BRP_CD

"NCCWL_" || IDのロード

DWR_SBRP

PROD_KEY

dwr_prodからのprod_keyのルックアップ

D Oracle Communications Billing and Revenue Managementアダプタの使用

この付録では、Oracle Communications Data ModelのOracle Communications Billing and Revenue Managementアダプタ(BRMアダプタ)を使用して、Oracle Communications Data Modelウェアハウスを移入する情報について説明します。

この付録のトピックは次のとおりです。

- Oracle Communications Data ModelのBRMアダプタの概要

- Oracle Communications Data ModelのBRMアダプタのコンポーネント

- Oracle Communications Data ModelのBRMアダプタの実行フロー

- Oracle Communications Data ModelのBRMアダプタを使用したウェアハウスの移入

- Oracle GoldenGateプロセスの確認

Oracle Communications Data ModelのBRMアダプタのインストールおよび構成の詳細は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

Oracle Communications Data ModelのBRMアダプタに関連付けられたオブジェクトおよびETLの詳細は、『Oracle Communications Data Modelリファレンス』を参照してください。

Oracle Communications Data ModelのBRMアダプタの概要

Oracle Communications Data ModelのOracle Communications Billing and Revenue Managementアダプタ(BRMアダプタ)は、Oracle Communications Data Modelのオプションです。

BRMアダプタは、Oracle Communications Billing and Revenue Managementソース・システムからOracle Communications Data Modelにデータをロードします。データは、初期ロードと増分ロードの2つの方法でロードできます。Oracle Communications Billing and Revenue Managementのデータが、Oracle Communications Data Modelの導出表と集計表、レポートおよびマイニング・モデルに移入されます。

Oracle Communications Data ModelのBRMアダプタのコンポーネント

Oracle Communications Data ModelのBRMアダプタは、次のコンポーネントを使用します。

- BRMソース・スキーマ表

- Oracle Communications Data ModelのBRMアダプタのデータベース・スキーマ

- Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義

- Oracle Data Integrator

- Oracle GoldenGate Replication: ステージング・データベースへのリアルタイム・データ入力に使用

- Oracle Communications Data Model

BRMソース・スキーマ表

Oracle Communications Data ModelのBRMアダプタは、表D-1にリストされている表からOracle Communications Data Modelにデータをロードします。

表D-1 BRMアダプタのソース表

BRMアダプタのソース表

ACCOUNT_NAMEINFO_T

ACCOUNT_T

BAL_GRP_T

BILL_T

BILLINFO_T

CONFIG_BEID_BALANCES_T

CONFIG_BUSINESS_TYPE_T

CONFIG_CUR_CONV_RATES_T

CONFIG_T

DD_OBJECTS_T

DEAL_PRODUCTS_T

DEAL_T

DISCOUNT_T

EVENT_ACTIVITY_TLCS_T

EVENT_ACTV_TLCS_SVC_CODES_T

EVENT_BAL_IMPACTS_T

EVENT_BILLING_PAYMENT_CASH_T

EVENT_BILLING_PAYMENT_CC_T

EVENT_BILLING_PAYMENT_CHECK_T

EVENT_BILLING_PAYMENT_DD_T

EVENT_BILLING_PAYMENT_FAILED_T

EVENT_BILLING_PAYMENT_PAYORD_T

EVENT_BILLING_PAYMENT_POST_T

EVENT_BILLING_PAYMENT_T

EVENT_BILLING_PAYMENT_WTRAN_T

EVENT_BROADBAND_USAGE_T

EVENT_DLAY_ACTV_TLCS_SVC_CDS_T

EVENT_DLAY_ACTV_TLCS_T

EVENT_DLAY_SESS_TLCS_SVC_CDS_T

EVENT_DLAY_SESS_TLCS_T

EVENT_DLYD_SESSION_TLCO_GPRS_T

EVENT_DLYD_SESSION_TLCO_GSM_T

EVENT_RUM_MAP_T

EVENT_SESS_TLCS_SVC_CODES_T

EVENT_SESSION_DIALUP_T

EVENT_SESSION_TELCO_GPRS_T

EVENT_SESSION_TLCO_GSM_T

EVENT_SESSION_TLCS_T

EVENT_T

EVENT_TAX_JURISDICTIONS_T

IFW_CURRENCY

IFW_TIMEZONE

IFW_USAGETYPE

INVOICE_T

ITEM_T

NOTE_T

PAYINFO_CC_T

PAYINFO_DD_T

PAYINFO_INV_T

PAYINFO_T

PLAN_SERVICES_T

PLAN_T

PRODUCT_T

PURCHASED_DISCOUNT_T

PURCHASED_PRODUCT_T

RATE_PLAN_T

SERVICE_EMAIL_T

SERVICE_T

SERVICE_TELCO_FEATURES_T

SERVICE_TELCO_GPRS_T

SERVICE_TELCO_GSM_T

Oracle Communications Data ModelのBRMアダプタのデータベース・スキーマ

Oracle Communications Data ModelのBRMアダプタは、次のデータベース・スキーマを使用します。

- ソース・スキーマ ソース・システムはOracle Communications Billing and Revenue Managementで、データベース・スキーマはBRM_SRC (PIN)です。
特定のソース・オブジェクトは、「BRMソース・スキーマ表」で説明します。

- ステージング・レイヤー・スキーマOracle Communications Data ModelのBRMアダプタは、BRMシステムからOracle Communications Data Modelウェアハウスの基盤レイヤー・オブジェクトにデータをロードする場合にステージング領域を使用します。ステージング・レイヤーは、変更済データおよび履歴データ格納のために使用され、Oracle Communications Data Model表をロードする場合にソース・スキーマとして使用されます。
Oracle Communications Data ModelのBRMアダプタは、brm_stgというデータベース・スキーマとしてステージングを定義します。

brm_stgスキーマは、「Oracle Communications Data ModelのBRMアダプタのステージング・スキーマ・オブジェクト」で説明します。

- ターゲット・スキーマOracle Communications Data ModelのBRMアダプタのターゲットは、Oracle Communications Data Modelウェアハウスです。特定のターゲット・オブジェクトは、Oracle Communications Data Modelの基盤レイヤー・オブジェクトです。これらのオブジェクトは、Oracle Communications Data Modelで提供されるocdm_sysスキーマで定義され、『Oracle Communications Data Modelリファレンス』に示されています。
Oracle Communications Data ModelのBRMアダプタのインストールは、ocdm_sysスキーマの追加プロシージャを定義します。これらのプロシージャは、「Oracle Communications Data ModelのBRMアダプタのOCDM_SYSオブジェクト」に記載されています。

Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義

『Oracle Communications Data Modelインストレーション・ガイド』の説明に従ってOracle Communications Data ModelのBRMアダプタをインストールおよび構成すると、次の定義が追加されます。

- アダプタで使用するステージング領域を定義するbrm_stgというデータベース・スキーマ。このデータベースの定義の詳細は、「Oracle Communications Data ModelのBRMアダプタのステージング・スキーマ・オブジェクト」を参照してください。

- Oracle Communications Data Modelウェアハウスの基盤レイヤーを移入するために使用するプロシージャ定義。これらの定義は、Oracle Communications Data Modelで提供されるocdm_sysスキーマに追加されます。これらのプロシージャの詳細は、「Oracle Communications Data ModelのBRMアダプタのOCDM_SYSオブジェクト」を参照してください。

Oracle Communications Data ModelのBRMアダプタのステージング・スキーマ・オブジェクト

Oracle Communications Data ModelのBRMアダプタのインストール後、ステージング・スキーマ(brm_stg)が作成されます。ステージング・スキーマには、次の表、ビュー、ファンクションおよびプロシージャが含まれます。

これらのオブジェクトが各BRMステージング・スキーマ(brm_stg)内に存在することを確認してください。

ステージング・スキーマ表

ロードされる各Oracle Communications Billing and Revenue Managementソース表に応じて、次の各表がステージング・スキーマで作成または更新されます。

- 通常のステージング表(XXX) (表名はソース表の名前と同じです)

- 前日表(XXX_LD)

- デルタ表(XXX_D)

- デルタ履歴表(XXX_D_H)

- Golden Gateオプション入力パラメータ表(BRM_MAPPING_TAB)

- ロード・パラメータ表BRM_ETL_PARAMETER (主に開始日、終了日およびロード日を保持)

ステージング・スキーマ・ビュー

Oracle Communications Data ModelのBRMアダプタで使用されるOracle Communications Billing and Revenue Managementソース・システム・ビューごとに、ステージング・スキーマ(brm_stg)に次の名前で2つのビューが作成されます(XXX_ vw)。

- EVENT_BILLING_PAYMENT_T_MAP_VW

- SERVICE_T_MAP_VW

ステージング・スキーマ・ファンクション

Oracle Communications Data ModelのBRMアダプタで使用されるOracle Communications Billing and Revenue Managementソース・システム・ファンクションごとに、ステージング・スキーマ(brm_stg)にUTC_TO_ORACLEというファンクションが作成されます。

ステージング・スキーマ・プロシージャ

日々のソース・データ変更およびデータ変更履歴を維持するため、Golden Gateオプションありの場合とGolden Gateオプションなしの場合の両方でステージング・スキーマ(brm_stg)に次の3つのプロシージャが作成されます。

- PRE_STAGING_LOAD (Oracle Golden Gateオプションあり)

- PRE_OCDM_LOAD (Oracle Golden Gateオプションなし)

- POST_STAGING_LOAD (Oracle Golden Gateオプションあり)

Oracle Communications Data ModelのBRMアダプタのOCDM_SYSオブジェクト

Oracle Communications Data ModelのBRMアダプタをインストールおよび構成すると、Oracle Communications Data Modelに付属のocdm_sysスキーマに次のプロシージャ定義が追加され、ocdm_sysスキーマにプロシージャが作成されて統合BRMデータが移入されます。

これらのオブジェクトがOracle Communications Data Modelスキーマ(ocdm_sys)内に存在することを確認してください。

プロシージャ

- DISB_CONS

- ENAB_CONS

- INSERT_REF

- SCD2_UPDATE

Oracle Data Integrator

Oracle Communications Data ModelのBRMアダプタは、Oracle Communications Data Modelの基盤レイヤー・オブジェクト(つまり、実表、参照表および検索表)の初期ロードを実行するETLとして、Oracle Data Integrator (ODI)で作成されたETLを使用します。また、ODI ETLを使用して、ステージング・データベースのスケジュール・リフレッシュも実行できます。

Oracle Communications Data ModelのBRMアダプタのODIの使用の詳細は、次のトピックを参照してください。

- BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)

- BRMアダプタを使用した実行フロー: Oracle GoldenGateおよびODIを使用

Oracle GoldenGate Replication

ODIを使用したOracle Communications Data Modelの基盤レイヤー・オブジェクトの初期ロードを実行した後、Oracle GoldenGateを使用してステージング・データベースに対するBRMソース・データのリアルタイム・フィードを実行できます。

Oracle Communications Data ModelのBRMアダプタのOracle GoldenGateの使用の詳細は、次のトピックを参照してください。

- 「リアルタイム・データによる基盤レイヤーのリフレッシュ」

- 「BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)」

Oracle Communications Data ModelのBRMアダプタの実行フロー

Oracle Communications Data ModelのBRMアダプタは、Oracle GoldenGateとともにアダプタを使用しているかどうかによって異なる実行フローを使用します。

- BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)

- BRMアダプタを使用した実行フロー: Oracle GoldenGateおよびODIを使用

BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)

Oracle Data Integrator (ODI)のみでOracle Communications Data ModelのBRMアダプタを使用できます。Oracle Communications Data ModelのBRMアダプタを使用するこの方法は、ODIプル・バージョンです。

図D-1に、ODIのみでアダプタを使用する場合(ODIプル・バージョン)のOracle Communications Data ModelのBRMアダプタの実行フローを示します。

図D-1 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー

「図D-1 Oracle GoldenGateなしでアダプタを使用する場合の実行フロー」の説明

ODIプル・バージョンには、定期的にデータをロードするオプションがあります。ODIプルのアプローチを使用する場合、実行フローは次のようになります(図D-1を参照)。

1. (手順1および3) BRMアダプタは、ODIを使用して、ソース・データベースからステージ・データベースにデータをロードします。

2. (手順2および5)事前および事後プロシージャを使用して、BRMアダプタは、最終日表(xxx_ld)、デルタ表(_delta)、履歴表など、データを複数のステージ・データベース表にロードします。

3. (図の手順4) BRMアダプタは、通常の表'MINUS'最終日表を使用して、ステージング領域のデルタ表をロードします。

4. (図の手順6) BRMアダプタは、デルタ表からOracle Communications Data Modelウェアハウスの基盤レイヤーにデータをロードします。

BRMアダプタを使用した実行フロー: Oracle GoldenGateおよびODIを使用

Oracle GoldenGateとともにOracle Communications Data ModelのBRMアダプタを使用してOracle Communications Data Modelウェアハウスの基盤レイヤーをリフレッシュする場合、この方法によって基盤レイヤー・データをBRMソース・データと同期できます。

図D-2に、Oracle GoldenGateでBRMアダプタを使用する場合のOracle Communications Data ModelのBRMアダプタの実行フローを示します。

図D-2 Oracle GoldenGateでBRMアダプタを使用する場合の実行フロー

「図D-2 Oracle GoldenGateでBRMアダプタを使用する場合の実行フロー」の説明

Oracle Communications Data ModelのBRMアダプタとともにOracle GoldenGateを使用する場合、実行フローは次のとおりです(図D-2を参照)。

1. Oracle Communications Data ModelのBRMアダプタのすべてのOracle GoldenGateプロセスが実行中であると想定すると、新しいデータがソース・データベースに挿入されるたびに、Oracle GoldenGateは新しい受信データを抽出し、それを使用してステージング表に移入します。

2. 図D-2の手順2および3 (ステージング領域): 実行プロセスのこの部分では、現行データや履歴データを含むすべての変更済データを保持できます。プロシージャSTG_OCDM_OGG_CDC_LOAD_SCENERIO_PKGがこのプロセスを処理します(これは、Oracle GoldenGate抽出プロセスによって通常の表が更新された後に実行されます)。

注意:
デルタ履歴表のデータのみ永久に残存し、常にソース・データと同期します。デルタ・ステージング表のデータがOracle Communications Data Modelウェアハウスの基盤レイヤーにロードされると、デルタ表が切り捨てられます。

3. 最終手順である図D-2の手順4では、デルタ表からOracle Communications Data Modelの基盤レイヤーにデータをロードします(これを実行するには、STG_OCDM_OGG_CDC_LOAD_PKGに依存するODIパッケージSTG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGを使用します)。

初期インストール後、増分ロードにOracle GoldenGateを使用する場合、最初に「BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)」に説明されているODIプルの手順を使用して、ソース・システムからステージング・システムに、およびステージング・システムからOracle Communications Data Modelにデータをロードする必要があります。初期ロード後、「リアルタイム・データによる基盤レイヤーのリフレッシュ」の説明に従って、増分ロードを設定してOracle Communications Data ModelデータとOracle Communications Billing and Revenue Managementソース・システムの同期を維持できます。

Oracle Communications Data ModelのBRMアダプタを使用したウェアハウスの移入

Oracle Communications Data ModelのBRMアダプタを使用して、Oracle Communications Data Modelウェアハウスの基盤レイヤー(つまり、ocdm_sysスキーマで定義された実表、参照表および検索表)を移入またはリフレッシュできます。詳細は、次を参照してください:

- Oracle Communications Data ModelのBRMアダプタを使用した初期ロード

- Oracle Communications Data ModelのBRMアダプタを使用したデータのリフレッシュ(チェンジ・データ・キャプチャ: CDC)

Oracle Communications Data ModelのBRMアダプタを使用して基盤レイヤーを移入した後、基盤レイヤーを移入するためにOracle Communications Data Modelのアプリケーション・アダプタを使用していない場合、同じようにOracle Communications Data Modelのアクセス・レイヤー(つまり、ocdm_sysスキーマで定義された導出表、集計表、OLAPキューブおよびデータ・マイニング・モデル)を移入またはリフレッシュします。詳細は、「アクセス・レイヤーの初期ロードの実行」および「Oracle Communications Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ」を参照してください。

Oracle Communications Data ModelのBRMアダプタを使用した初期ロード

Oracle Communications Data ModelのBRMアダプタとOracle Data Integrator (ODI)を使用してOracle Communications Data Modelウェアハウスの基盤レイヤーの初期ロードを実行するには、次の手順に従います。

1. インストールおよび構成で「Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

参照:
ODIで使用するOracle Communications Data ModelのBRMアダプタのインストールおよび構成の手順は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

2. BRM_ETL_PARAMETERを設定します。

1. ステージング・スキーマ(brm_stgなど)に接続します。

2. 表BRM_ETL_PARAMETERからデータを削除し、次の値を設定します。

FROM_DATE_ETL=01/01/1900;
TO_DATE_ETL=current time of BRM system;
LOAD_DT=sysdate

次に例を示します。

delete from brm_etl_parameter;
commit;
Insert into BRM_ETL_PARAMETER
(PROCESS_NAME, FROM_DATE_ETL, TO_DATE_ETL, LOAD_DT)
Values ('BRM-ADAPTER', TO_DATE('01/01/1900 00:00:00', 'MM/DD/YYYY HH24:MI:SS'), TO_DATE('05/22/2012 10:28:55', 'MM/DD/YYYY HH24:MI:SS'), sysdate);
commit;

注意: 現在のOracle Communications Billing and Revenue Managementの時刻は、pvt (pin_virtual_time)で取得できます。

3. ODI Studio Designerから、BRM_OCDMプロジェクトに移動して、次の手順に従います。

1. 「SRC_STG_NONOGG」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- SRC_STG_LOAD_NON_OGG_PKG

2. 「STG_OCDM」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- STG_OCDM_INITIAL_LOAD_PKG

参照:
初期ロードの実行フローの詳細は、「BRMアダプタを使用した実行フロー: ODIプル・バージョン(Oracle GoldenGateなし)」を参照してください。

Oracle Communications Data ModelのBRMアダプタを使用したデータのリフレッシュ(チェンジ・データ・キャプチャ: CDC)

Oracle Communications Data Modelウェアハウスの初期データ・ロードを実行した後に、データをリフレッシュする必要がある場合、ODIを使用してOracle Communications Data Modelウェアハウスのステージング領域および基盤レイヤーのすべてのデータをリフレッシュします。

スケジュール単位の基盤レイヤーのリフレッシュ

Oracle Communications Data Modelウェアハウスの基盤レイヤーを移入するためにOracle GoldenGateとともにOracle Communications Data ModelのBRMアダプタを使用していない場合、Oracle Data Integrator (ODI)を使用してスケジュール単位で基盤レイヤーをリフレッシュします。

ODIのみを使用して基盤レイヤーのデータをリフレッシュするには、次の手順に従います。

1. インストールおよび構成で「Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

参照:
ODIで使用するOracle Communications Data ModelのBRMアダプタのインストールおよび構成の手順は、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

2. BRM_ETL_PARAMETER表のパラメータ値をリセットします。

1. ステージング・スキーマ(brm_stgなど)に接続します。

2. 表BRM_ETL_PARAMETERからデータを削除し、次の値を設定します。

FROM_DATE_ETL=TO_DATE_ETL(last time loading)+ 1 second;
TO_DATE_ETL=current time of BRM system;
LOAD_DT = time when loading

次に例を示します。

delete from brm_etl_parameter;
commit;
Insert into BRM_ETL_PARAMETER
(PROCESS_NAME, FROM_DATE_ETL, TO_DATE_ETL, LOAD_DT)
Values ('BRM-ADAPTER', TO_DATE('05/22/2012 10:28:56', 'MM/DD/YYYY HH24:MI:SS'), TO_DATE('05/24/2012 10:28:55', 'MM/DD/YYYY HH24:MI:SS'), sysdate);
commit;

注意: 現在のOracle Communications Billing and Revenue Managementの時刻は、pvt (pin_virtual_time)で取得できます。

3. ODI Studio Designerから、BRM_OCDMプロジェクトに移動して、次の手順に従います。

1. 「SRC_STG_NONOGG」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- SRC_STG_LOAD_NON_OGG_PKG

2. 「STG_OCDM」、「パッケージ」の順に選択して、次のパッケージを選択および実行します。

- STG_OCDM_INITIAL_LOAD_PKG

リアルタイム・データによる基盤レイヤーのリフレッシュ

「Oracle Communications Data ModelのBRMアダプタを使用した初期ロード」の説明に従ってOracle Communications Data Modelウェアハウスの初期ロードを実行した後、リアルタイムでOracle Communications Data Modelウェアハウスの基盤レイヤーのデータをリフレッシュできます。

この方法でOracle Communications Data Modelウェアハウスの基盤レイヤーのデータを確認するには、次の手順に従います。

1. 『Oracle Communications Data Modelインストレーション・ガイド』の説明に従って、Oracle Communications Data ModelのBRMアダプタをインストールして、Oracle GoldenGateおよびOracle Data Integrator (ODI)で使用するために構成します。
インストールおよび構成で「Oracle Communications Data ModelのBRMアダプタで追加したスキーマ定義」に示されているスキーマ・オブジェクトが作成されたことを確認します。

2. 図D-2に示すように、Oracle GoldenGateは手順1を処理します。実行する必要があるのは、ソース・システムとステージング・システムのOracle GoldenGateプロセスが実行モードであるかどうかを確認することのみです(すべてのGoldenGateプロセスは、チェックポイント情報を保持しており、プロセスが異なる位置から再起動するように変更されていないかぎり、データ損失なしでクラッシュ・ポイントから再起動します)。
GGSCIプロンプトから、info allコマンドを発行して、Oracle Communications Data ModelのBRMアダプタで必要なOracle GoldenGateプロセスが実行されていることを確認します。

ソース・システム・プロセス

ステージング・システム・プロセス

マネージャ・プロセス
抽出プロセス(EXTBRM)

抽出ポンプ・プロセス(EXTPBRM)

マネージャ・プロセス
レプリケート・プロセス(REPBRM)

次のコードは、これらのコマンドを発行した正常な結果を示しています。

GGSCI>  (mypc1)  5> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
EXTRACT    RUNNING  EXTBRM   47:29:00   00:00:20
EXTRACT    RUNNING  EXTPBRM  00:00:00   47:29:06

GGSCI>  (ocdm01)  2> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
REPLICAT   RUNNING  REPBRM   00:00:00   00:03:09

ヒント:
2つのソース・システムがある場合、2つのソース・システムのプロセス・ステータスを確認します。
Oracle GoldenGateプロセスを管理するコマンドは、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

3. 図D-2に示すように手順2、3、4を実行するには、ODIを使用してSTG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージを実行します。
ODI Studio Designerから、BRM_OCDMプロジェクトに移動して、次の手順に従います。

1. 「STG_OCDM」、「パッケージ」の順に選択して、STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGを選択および実行します。

参照:
実行フローの詳細は、「BRMアダプタを使用した実行フロー: Oracle GoldenGateおよびODIを使用」を参照してください。

注意:
STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGは、シナリオ・ベースのパッケージで、1つのパッケージとSCD2_UPDATEプロシージャを含みます。このパッケージは、複数のインタフェースとプロシージャPRE_OCDM_LOADで構成されるSTG_OCDM_OGG_CDC_LOAD_PKGという別のパッケージに基づきます。STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGは、ステージング・システムからOCDM_SYSターゲットへのデータ・ロードの実行を待機します。

ODI BRM_OCDMプロジェクト

この項では、「Oracle Communications Data ModelのBRMアダプタを使用した初期ロード」および「Oracle Communications Data ModelのBRMアダプタを使用したデータのリフレッシュ(チェンジ・データ・キャプチャ: CDC)」で説明されている各実行可能オブジェクトによって実行される内部操作について説明します。

BRM_OCDMプロジェクトのSRC_STG_NONOGGフォルダのオブジェクト

SRC_STG_LOAD_NON_OGG_PKGパッケージ

BRM_OCDMプロジェクトのSRC_STG_NONOGGフォルダのSRC_STG_LOAD_NON_OGG_PKGパッケージは、BRMソース・データベースからBRMステージング・データベースにデータをロードするために使用されます。ステージング・データベースをロードするこのプロセスには、次の手順が含まれていました。

1. PRE_STAGING_LOADプロシージャを実行して前日表(XXX_LD)をロードします。このプロシージャは、次の操作を実行します。

1. 前日表(XXX_LD)を削除します。

2. 通常のステージング表の名前(XXX)を前日表の名前(XXX_LD)に変更します。

3. 前日表(XXX_LD)から通常のステージング表(XXX)の構造を作成します。

(XXX_LDの削除→XXXからXXX_LDへの名前変更→XXX_LDからのXXXの作成)。

2. Golden Gate以外のインタフェース(XXX_NONGG)を1つずつ作成して通常のステージング表(XXX)をロードします。
Golden Gate以外のインタフェースは101個あり、そのうち51個のネーミング・ルールはXXX_NONGGで、他の51個のネーミング・ルールはXXX_NONGG_IUです。これらは順番に実行され、ソース表からステージング表がロードされます(src.XXXからstg.XXX)。

SRC_STG_NONGGインタフェース:

1.     ACCOUNT_NAMEINFO_T_NONGG_IU
2.     ACCOUNT_NAMEINFO_T _NONGG
3.     ACCOUNT_T_NONGG_IU
4.     ACCOUNT_T_NONGG
5.     BAL_GRP_T_NONGG_IU
6.     BAL_GRP_T_NONGG
7.     BILLINFO_T_NONGG_IU
8.     BILLINFO_T_NONGG
9.     BILL_T_NONGG_IU
10.     BILL_T_NONGG
11.     CONFIG_T_NONGG_IU
12.     CONFIG_T_NONGG
13.     CONFIG_BEID_BALANCES_T_NONGG_IU
14.     CONFIG_BEID_BALANCES_T_NONGG
15.     CONFIG_BUSINESS_TYPE_T_NONGG_IU
16.     CONFIG_BUSINESS_TYPE_T_NONGG
17.     CONFIG_CUR_CONV_RATES_T_NONGG_IU
18.     CONFIG_CUR_CONV_RATES_T_NONGG
19.     DD_OBJECTS_T_NONGG_IU
20.     DD_OBJECTS_T_NONGG
21.     DEAL_PRODUCTS_T_NONGG_IU
22.     DEAL_PRODUCTS_T_NONGG
23.     DEAL_T_NONGG_IU
24.     DEAL_T_NONGG
25.     DISCOUNT_T_NONGG_IU
26.     DISCOUNT_T_NONGG
27.     EVENT_BAL_IMPACTS_T_NONGG_IU
28.     EVENT_BAL_IMPACTS_T_NONGG
29.     EVENT_BILLING_PAYMENT_CASH_T_NONGG_IU
30.     EVENT_BILLING_PAYMENT_CASH_T_NONGG
31.     EVENT_BILLING_PAYMENT_CC_T_NONGG_IU
32.     EVENT_BILLING_PAYMENT_CC_T_NONGG
33.     EVENT_BILLING_PAYMENT_CHECK_T_NONGG_IU
34.     EVENT_BILLING_PAYMENT_CHECK_T_NONGG
35.     EVENT_BILLING_PAYMENT_DD_T_NONGG_IU
36.     EVENT_BILLING_PAYMENT_DD_T_NONGG
37.     EVENT_BILLING_PAYMENT_FAILED_T_NONGG_IU
38.     EVENT_BILLING_PAYMENT_FAILED_T_NONGG
39.     EVENT_BILLING_PAYMENT_PAYORD_T_NONGG_IU
40.     EVENT_BILLING_PAYMENT_PAYORD_T_NONGG
41.     EVENT_BILLING_PAYMENT_POST_T_NONGG_IU
42.     EVENT_BILLING_PAYMENT_POST_T_NONGG
43.     EVENT_BILLING_PAYMENT_T_NONGG_IU
44.     EVENT_BILLING_PAYMENT_T_NONGG
45.     EVENT_BILLING_PAYMENT_WTRAN_T_NONGG_IU
46.     EVENT_BILLING_PAYMENT_WTRAN_T_NONGG
47.     EVENT_BROADBAND_USAGE_T_NONGG_IU
48.     EVENT_BROADBAND_USAGE_T_NONGG
49.     EVENT_SESSION_DIALUP_T_NONGG_IU
50.     EVENT_SESSION_DIALUP_T_NONGG
51.     EVENT_SESSION_TELCO_GPRS_T_NONGG_IU
52.     EVENT_SESSION_TELCO_GPRS_T_NONGG
53.     EVENT_SESSION_TLCO_GSM_T_NONGG_IU
54.     EVENT_SESSION_TLCO_GSM_T_NONGG
55.     EVENT_SESSION_TLCS_T_NONGG_IU
56.     EVENT_SESSION_TLCS_T_NONGG
57.     EVENT_SESS_TLCS_SVC_CODES_T_NONGG_IU
58.     EVENT_SESS_TLCS_SVC_CODES_T_NONGG
59.     EVENT_T_NONGG_IU
60.     EVENT_T_NONGG
61.     IFW_CURRENCY_NONGG_IU
62.     IFW_CURRENCY_NONGG
63.     IFW_TIMEZONE_NONGG_IU
64.     IFW_TIMEZONE_NONGG
65.     IFW_USAGETYPE_NONGG_IU
66.     IFW_USAGETYPE_NONGG
67.     INVOICE_T_NONGG_IU
68.     INVOICE_T_NONGG
69.     ITEM_T_NONGG_IU
70.     ITEM_T_NONGG
71.     NOTE_T_NONGG_IU
72.     NOTE_T_NONGG
73.     PLAN_SERVICES_T_NONGG_IU
74.     PLAN_SERVICES_T_NONGG
75.     PLAN_T_NONGG_IU
76.     PLAN_T_NONGG
77.     PRODUCT_T_NONGG_IU
78.     PRODUCT_T_NONGG
79.     PURCHASED_DISCOUNT_T_NONGG_IU
80.     PURCHASED_DISCOUNT_T_NONGG
81.     PURCHASED_PRODUCT_T_NONGG_IU
82.     PURCHASED_PRODUCT_T_NONGG
83.     RATE_PLAN_T_NONGG_IU
84.     RATE_PLAN_T_NONGG
85.     SERVICE_EMAIL_T_NONGG_IU
86.     SERVICE_EMAIL_T_NONGG
87.     SERVICE_TELCO_FEATURES_T_NONGG_IU
88.     SERVICE_TELCO_FEATURES_T_NONGG
89.     SERVICE_TELCO_GPRS_T_NONGG_IU
90.     SERVICE_TELCO_GPRS_T_NONGG
91.     SERVICE_TELCO_GSM_T_NONGG_IU
92.     SERVICE_TELCO_GSM_T_NONGG
93.     SERVICE_T_NONGG_IU
94.     SERVICE_T_NONGG
95.     PAYINFO_T_NONGG_IU
96.     PAYINFO_T_NONGG
97.     PAYINFO_CC_T_NONGG_IU
98.     PAYINFO_CC_T_NONGG
99.     PAYINFO_DD_T_NONGG_IU
100.     PAYINFO_DD_T_NONGG
101.     PAYINFO_INV_T_NONGG_IU
102.     PAYINFO_INV_T_NONGG

3. POST_STAGING_LOADプロシージャを実行してデルタ表(XXX _DELTA)およびデルタ履歴表(XXX_DELTA_H)にデータをロードします。

1. デルタ表(XXX _DELTA)を切り捨てます。

2. 通常のステージング表(XXX)および前日表(XXX_LD)からデルタ表(XXX _DELTA)にデータを挿入します。

3. ソース変更(OPTYPE、LAST_UPDATE_TIMEおよびCHANGE_DATE)に応じてデルタ表(XXX _DELTA)の列を更新します。

4. デルタ表(XXX _DELTA)からデルタ履歴表(XXX_DELTA_H)にデータを挿入します。

(XXX_DELTAの切捨て→XXXとXXX_LDの差分からXXX_DELTAへの挿入→XXX_DELTAからXXX_DELTA_Hへの挿入)

SRC_STG_LOAD_NON_OGG_PKGパッケージ

BRM_OCDMプロジェクトのSRC_STG_NONOGGフォルダのSRC_STG_LOAD_NON_OGG_PKGパッケージは、ステージング・デルタ表およびデルタ履歴表をロードするために使用されます。このパッケージは、PRE_OCDM_LOADプロシージャをコールして無限ループで実行します。反復ループごとに、次の手順を実行して、デルタ表(XXX _DELTA)およびデルタ履歴表(XXX_DELTA_H)にデータをロードします。

1. デルタ表(XXX _DELTA)からデルタ履歴表(XXX_DELTA_H)にデータを挿入します。

2. デルタ表(XXX _DELTA)を切り捨てます。

3. 通常のステージング表(XXX)からデルタ表(XXX _DELTA)にデータを挿入します。

4. 任意のXXX _DELTA表の新しいデータを待機して、ODIは、待機状態になるODI WAIT FOR DATAというツールを使用します。このツール(ODI WAIT FOR DATA)の作業は、ステージング・レイヤーのデルタ表(XXX _DELTA)のデータ変更を待機することです。変更が検出されると、関連するOCDM基盤レイヤー表にデータを移入する適切なインタフェースが実行されます。

(XXX_DELTAからXXX_DELTA_Hへの挿入、XXX_DELTAの切捨て、およびXXXからXXX_DELTAへの挿入)

BRM_OCDMのSTG_OCDMフォルダのオブジェクト

STG_OCDM_INITIAL_LOAD_PKGパッケージ

BRM_OCDMプロジェクトのSTG_OCDMフォルダのSTG_OCDM_INITIAL_LOAD_PKGパッケージは、BRMステージング・データベースのデルタ表(XXX _DELTA)からOCDM基盤レイヤー表をロードします。STG_OCDM_INITIAL_LOAD_PKGパッケージは、順番に実行される46個のSTG-OCDMインタフェース(XXX_MAP)を実行し、これによりデータがステージング・デルタ表(XXX _DELTA)から関連するOCDM基盤レイヤー表に移入されます。

STG-OCDMインタフェース:

1.     ACCOUNT_ACCT_MAP
2.     ACCOUNT_ADDR_LOC_MAP
3.     ACCOUNT_CUST_MAP
4.     ACCOUNT_GEO_CITY_MAP
5.     ACCOUNT_GEO_CNTRY_MAP
6.     ACCOUNT_GEO_STATE_MAP
7.     ACCOUNT_INVC_DLVRY_MAP
8.     ACCOUNT_POSTCD_MAP
9.     ACCOUNT_PRTY_CNCT_INFO_MAP
10.     ACCOUNT_PRTY_MAP
11.     BAL_GRP_GRP_MAP
12.     BILLINFO_ACCT_MAP
13.     BILLINFO_PYMT_MTHD_TYP_MAP
14.     BILL_INVC_MAP
15.     CONFIG_BEID_BAL_TYP_MAP
16.     CONFIG_BUSINESS_TYPE_T_MAP
17.     CONFIG_CUR_CRNCY_EXCHNG_RATE_MAP
18.     DD_OBJECTS_SRVC_SPEC_MAP
19.     DEAL_PKG_ASGN_MAP
20.     DEAL_PROD_MAP
21.     EVENT_BAL_IMPACTS_NTWK_EVT_ACCT_BAL_IMPC_MAP
22.     EVENT_BILLING_ACCT_RCHRG_MAP
23.     EVENT_BROADBAND_USAGE_BRDBND_USG_EVT_MAP
24.     EVENT_CALL_EVT_MAP
25.     EVENT_DATA_SRVC_EVT_MAP
26.     EVENT_SESSION_GPRS_USG_EVT_MAP
27.     IFW_CRNCY_MAP
28.     IFW_TIMWZONE_TIME_MAP
29.     IFW_USAGETYPE_SRVC_TYP_MAP
30.     INVOICE_INVC_DLVRY_MAP
31.     ITEM_INVC_ITEM_MAP
32.     NOTE_EVT_PRTY_INTRACN_MAP
33.     PAYINFO_ACCT_PREF_PYMT_MTHD_MAP
34.     PAYINFO_CC_PRTY_MAP
35.     PAYINFO_DD_PRTY_MAP
36.     PAYINFO_INV_T_PRTY_MAP
37.     PLAN_MKT_PLN_MAP
38.     PLAN_SERVICES_PROD_MKT_PLN_ASGN_MAP
39.     PRODUCT_DISCOUNT_PROD_MAP
40.     PRODUCT_DISCOUNT_PROD_RLTN_MAP
41.     PURCHASED_PRODUCT_PRICE_CHRG_MAP
42.     PURCHASED_PRODUCT_SBRP_MAP
43.     RATE_PLAN_PROD_RTNG_PLN_MAP
44.     SERVICE_CUST_FCNG_SRVC_MAP
45.     SERVICE_SRVC_STAT_HIST_MAP
46.     SERVICE_TELCO_FEATURES_SRVC_CHTRSTC_MAP

STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージ

次に説明するBRM_OCDMプロジェクトのSTG_OCDMフォルダのSTG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGパッケージは、OCDM基盤レイヤー表の移入インタフェースを実行します(これらのパッケージを実行し、実行モードに移行する必要があります)。

注意: STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGは、STG_OCDM_OGG_CDC_LOAD_PKGパッケージおよびSCD2_UPDATEプロシージャを含むパッケージであり、シナリオ・パッケージは、46個のインタフェースとPRE_OCDM_LOADプロシージャで構成されるSTG_OCDM_OGG_CDC_LOAD_PKGに基づきます。STG_OCDM_OGG_CDC_LOAD_SCENARIO_PKGは、無限ループ・プロセス内に存在し、ステージ(BRM_STG)からターゲット(OCDM_SYS)へのデータ・ロードの実行を待機します。

Oracle GoldenGateプロセスの確認

Oracle GoldenGateを使用している場合、アダプタがステージング・システムにデータをロードできるようにOracle GoldenGateが動作していることを確認してください。リストされているプロセスが、次のようにソース・システムとステージング・システムの両方で実行されている必要があります。

ソース・プロセス

- マネージャ・プロセス

- 抽出プロセス(EXTBRM)

- 抽出ポンプ・プロセス(EXTPBRM)

たとえば、BRM_SRCソース・システムでは、ソース・プロセスが次のように表示されます。

GGSCI>  (mypc1)  5> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
EXTRACT    RUNNING  EXTBRM   47:29:00   00:00:20
EXTRACT    RUNNING  EXTPBRM  00:00:00   47:29:06

ステージング・プロセス

GGSCI>  (ocdm01)  2> info all

Program    Status   Group    Lag        Time Since Chkpt

MANAGER    RUNNING
REPLICAT   RUNNING  REPBRM   00:00:00   00:03:09

ヒント:
2つのソース・システムがある場合、2つのソース・システムのプロセス・ステータスを確認します。Oracle GoldenGateプロセスを管理するコマンドは、『Oracle Communications Data Modelインストレーション・ガイド』を参照してください。

E Oracle Communications Data Modelのアップグレード

この付録では、Oracle Communications Data Modelのアップグレード方法について説明します。内容は次のとおりです。

- Oracle Communications Data Modelのアップグレードの準備

- Oracle Communications Data Modelのアップグレード・パス

- Oracle Communications Data Modelの回帰テスト

注意:
詳細なアップグレード手順および説明は、各Oracle Communications Data Modelアップグレード・パッケージで示されています。この付録では、Oracle Communications Data Modelのアップグレード方法の一般的な情報について説明します。

Oracle Communications Data Modelのアップグレードの準備

Oracleには、製品ロードマップおよびライフサイクル管理があります。また、Oracle Communications Data Model製品およびエンジニアリング・チームは、特定の業界の傾向、進歩およびベスト・プラクティスを監視して、Oracle Communications Data Modelにこれらの機能を導入します。

次のリリースのOracle Communications Data Modelでは、アップグレードする必要があるOracle Communications Data Modelのコンポーネントを識別し、アップグレードが既存のデータ・ウェアハウス・アーキテクチャおよびアプリケーションに与える影響を分析します。Oracle Communications Data Modelのアップグレードは、Oracle Communications Data Model自体に焦点を当てています。ハードウェア・プラットフォームまたは関連ソフトウェアのアップグレードは考慮しません。

Oracle Communications Data Modelアップグレード・パッケージを取得した後、アップグレードの次の手順に従います。

1. アップグレードの目的およびプロセスを理解し、既存のデータ・ウェアハウス・システムの影響を分析して、受け入れるかどうかを決定します。受け入れた場合は、次の手順に進みます。

2. ソフトウェア・バージョン要件など、関連する環境要件を確認します。

3. 現在のスキーマをバックアップします。

4. Oracle Communications Data Modelを以前にカスタマイズした場合、アーカイブした元のOracle Communications Data Modelスキーマを準備して、それ以外の場合はこの手順をスキップします。

5. 特定のアップグレード・パス・ガイドの「Oracle Communications Data Modelのアップグレード・パス」に従います。

6. Oracleアップグレード・スクリプトの後の追加アップグレード・タスクをリストします。

7. パッチ・スクリプトとして、Oracleアップグレード・スクリプトの後の追加の変更を行います。

Oracle Communications Data Modelのアップグレード・パス

Oracle Communications Data Modelをアップグレードする2つの異なるパスがあります。Oracle Communications Data Modelをカスタマイズしたかによって異なります。

アップグレード・パスA: 以前のデフォルトのOracle Communications Data Modelに基づく

次の手順に従って、以前のデフォルトのOracle Communications Data Modelに基づいてOracle Communications Data Modelをアップグレードします。

1. アップグレード・スクリプトの要件を満たしていることを確認します。

2. アップグレード・スクリプトを実行します。

3. 必要に応じて、データを移行します。

4. 必要に応じて追加する変更は次のとおりです。

- 導出された集計レイヤー

- Source-ETLおよびIntra-ETLマッピング

- ワークフロー

- ビジネス・インテリジェンス・アプリケーション

- メタデータ・リポジトリ

アップグレード・パスB: カスタマイズしたOracle Communications Data Modelに基づく

次の手順に従って、カスタマイズしたOracle Communications Data Modelに基づいてOracle Communications Data Modelをアップグレードします。

1. アップグレード・スクリプトの要件を満たしていることを確認します。

2. アップグレード前に元のOracle Communications Data Modelをリストアします。

3. 元のOracle Communications Data Modelに基づいて、Oracleアップグレード・スクリプトを実行します。

4. 必要に応じて、カスタマイズ・パッチおよびアップグレードを確認します。

5. (新しい)カスタマイズ・パッチを実行します。

6. データを移行します。

7. 必要に応じて追加する変更は次のとおりです。

- 導出された集計レイヤー

- Source-ETLおよびIntra-ETLマッピング

- ワークフロー

- ビジネス・インテリジェンス・アプリケーション

- メタデータ・リポジトリ

Oracle Communications Data Modelの回帰テスト

Oracle Communications Data Modelをアップグレードした後、回帰テストを実行します。実行する主要なタスクは、次のとおりです。

- テスト計画を作成します。

- テスト・ケースを実行します。

- エラー処理をテストします。

- 最終的なレポートを作成します。

索引

A  B  C  D  E  F  H  I  J  K  L  M  N  O  P  Q  R  S  T  U

A

アクセス・レイヤー, 2.1

カスタマイズ, 3, 3.1

Oracle Communications Data Model, 2.1, 3

Oracle Communications Data Modelのアクセス・レイヤー

移入, 4.4.2, 4.5.2

アカウント

Oracle Communications Dataウェアハウス, B.1

AGGR_FLW, 4.3 集計表

Oracle Communications Data Model, 3.3

リフレッシュ, 4.3

アプリケーション・アダプタ

Oracle Communications Data Model, C, D

Oracle Communications Data Model, 4.2, 4.2.1, 4.5.1

As Isレポート, 5.6.1 As Wasレポート, 5.6.1

B

Billing and Revenue Managementアダプタ

Oracle Communications Data Model, D

Oracle Communications Data ModelのBRMアダプタ, D.2.3.2

概要, D, D.1

移入の使用, D.4

スキーマ, D.2.2

ODIを使用, D.2.4

Oracle GoldenGateを使用, D.2.5

brm_stgスキーマ, D.2.3

C

チャーン予測データ・マイニング・モデル, 3.2.2.3

圧縮

Oracle Communications Data Model, 2.4.2, 2.4.2.1, 2.4.2.1.1

マテリアライズド・ビュー, 3.5.4

Oracle Communications Data Modelウェアハウスの構成, A.2 表記規則

物理モデルをカスタマイズする場合, 2.2.2

キューブ

マテリアライズド・ビュー機能の追加, 3.4.3.2

ディメンションの変更, 3.4.6

メジャーの変更, 3.4.6

カスタマイズ, 3.4.4

データのメンテナンス方法, 3.4.9

予測, 3.4.7

Oracle Communications Data Model, 3.4.4, 3.4.5

パーティション化, 3.4.8

カスタマイズ

アクセス・レイヤー, 3

キューブ, 3.4.4

Oracle Communications Data Model, 1.2

物理データ・モデル, 2

D

ダッシュボード, Oracle Communications Data Model, 5.2, 5.7

データ管理委員会, 責任, 1.3.2

データ・マイニング・モデル

カスタマイズ, 3.2.2

リフレッシュ, 4.3

ocdm_sysに追加される定義, C.4.2.2, D.2.3.2 導出表

Oracle Communications Data Model, 3.2

リフレッシュ, 4.3

次元コンポーネント, Oracle Communications Data Model, 3.4 DRVD_FLW, 4.3

E

エラー処理

Intra-ETLの実行中, 4.6

Oracle Communications Data ModelのETL, 4.1

F

Oracle Communications Data Modelのフィットギャップ分析, 1.5

Oracle Communications Data Modelの予測キューブ, 3.4.7

基盤レイヤー

定義, 2.1

Oracle Communications Data Model, 2.1

Oracle Communications Data Modelの基盤レイヤー

一般的な変更シナリオ, 2.3.1

移入, 4.4.1, 4.5.1

H

HCC, 2.4.2.1.3

Hybrid Columnar圧縮

Oracle Communications Data Model, 2.4.2.1.3

I

Oracle Communications Data Modelの実装者

前もって必要な知識, 13.1

実装

Oracle Communications Data Model, 1.2

インデックス

Oracle Communications Data Model, 2.4.6

マテリアライズド・ビュー, 3.5.2

パーティション化, 2.4.6

整合性制約

Oracle Communications Data Model, 2.4.5

INTRA_ETL_FLWプロセス・フロー, 4.3 Intra-ETL

カスタマイズ, 4.3

実行, 4.4.2.1

エラーの管理, 4.6

実行の監視, 4.6.1

Oracle Communications Data Model, 4.1

リカバリ, 4.6.2

トラブルシューティング、4.6.3

J

結合パフォーマンス, 改善, 2.4.7.3

K

キー, サロゲート

Oracle Communications Data Model, 2.4.4

L

Oracle Communications Data Modelデータのロード, 4.4, 4.4.2

M

マテリアライズド・ビュー, 3.5.1

圧縮, 3.5.4

Oracle Communications Data Model, 3.5

索引, 3.5.2

パーティション・チェンジ・トラッキング, 3.5.3

パーティション化, 3.5.3

リフレッシュ・オプション

リフレッシュ, 3.5.1

メタデータ依存性マネージャ

Oracle Communications Data Model, 1.4.4

メタデータ管理

リポジトリ, 1.4.2, 1.4.3

Oracle Communications Data Model, 1.4

メタデータ・リポジトリ, 1.4.2

参照, 1.4.3

Oracle Communications Data Model, 1.4.3

MINING_FLW, 4.3

N

ネーミング規則

Oracle Communications Data Modelの物理モデル, 2.2.2

Oracle Communications Data ModelのNCCアダプタ, C.4.2.2

コンポーネント, C.4

概要, C, C.1

ODIプロジェクト, C.4.3

移入の使用, C.2

スキーマ, C.1.1

ODIを使用, C.1.2

Oracle GoldenGateを使用, C.1.3

NCCソース・スキーマ, C.4.1 NCC_OCDMプロジェクト, C.4.3 ncc_stgスキーマ, C.4.2 Network Charging and Controlアダプタ

Oracle Communications Data Model, C

Oracle Communications Data ModelのNetwork Charging and Controlアダプタ, 4.2.1

O

ocdm_sysスキーマ

Oracle Communications Data ModelのBRMアダプタで追加される定義, D.2.3.2

Oracle Communications Data ModelのNCCアダプタで追加される定義, C.4.2.2

ODI

Oracle Communications Data ModelのBRMアダプタ, D.2.4

Oracle Communications Data ModelのNCCアダプタ, C.1.2

ODIプロジェクト

Oracle Communications Data ModelのNCCアダプタ, C.4.3

Oracle Communications Data Model

アクセス・レイヤー, 2.1, 3

アカウント, B.1

アプリケーション・アダプタ, 4.2, 4.2.1, 4.5.1

Billing and Revenue Managementアダプタ, D

コンポーネント, 1.1.1

カスタマイズ, 1.2

物理モデルのカスタマイズ, 2.1, 2.2, 2.2.1, 2.2.2, 2.4

ダッシュボード, 5.2

データ管理, 1.3.2

説明, 1.1

次元コンポーネント, 3.4

ETL, 4.1

フィットギャップ分析, 1.5

基盤レイヤー, 2.1

実装, 1.2

Intra-ETL, 4.1

ロード, 4.4, 4.4.2

メタデータ依存性マネージャ, 1.4.4

メタデータ管理, 1.4

メタデータ・リポジトリ, 1.4.2, 1.4.3

Network Charging and Controlアダプタ, C

使用されるOracle製品, 1.1.2

Oracle Warehouse Builder, 使用, 1.4.4

物理レイヤー, 2.1

Oracle Communications Data ModelのBRMアダプタを使用した移入, D.4

Oracle Communications Data ModelのNCCアダプタを使用した移入, C.2

実装前タスク, 1.3

問合せ, 5.3

データのリフレッシュ, 4.5

リアルタイム・データを使用したリフレッシュ, C.2.2, C.3.1, D.4.2

BRMアダプタでのリアルタイム・データを使用したリフレッシュ, D.3.2

レポート, 5.1, 5.3

Source-ETL, 4.1, 4.2, 4.2.2.2, 4.2.2.3, 4.2.2.4, 4.2.2.5

ステージング・レイヤー, 2.1

表領域, 設計の推奨事項, 2.4.1

アップグレード, E

ユーザー権限, B

Oracle Communications Data Model実装者

前提知識, 1.3.1

Oracle Communications Data Modelウェアハウス

構成, A.2

サイズ設定, A.1

Oracleデータ・マイニング・モデル

Oracle Communications Data Model, 3.2.2.1

Oracle GoldenGate

Oracle Communications Data ModelのBRMアダプタ, D.2.5

Oracle Communications Data ModelのNCCアダプタ, C.1.3

Oracle Warehouse Builder

Oracle Communications Data Model, 1.4.4

P

パラレル実行

セッションに対する有効化, 2.4.8.1

DML操作に対する有効化, 2.4.8.2

Oracle Communications Data Model, 2.4.8

パーティション・チェンジ・トラッキング, 3.5.3 パーティション交換ロード, 4.2.2.7.5 Oracle Communications Data Modelのパーティション索引, 3.4.7 パーティション化

キューブ, 3.4.8

簡易データ・アクセス, 2.4.7.2

結合パフォーマンス, 2.4.7.3

管理性, 2.4.7.1

Source-ETL, 4.2.2.7.5

索引, 2.4.6

マテリアライズド・ビュー, 3.5.3

表, 2.4.7

パーティション, 変更, 2.4.1 Oracle Communications Data Modelの物理モデル

特性, 2.1, 2.2, 2.2.1

カスタマイズ, 2.2.2

一般的な推奨事項, 2.4

Q

Oracle Communications Data Modelの問合せ, 5.3

R

リアルタイム・データ

移入, C.2.2, C.3.1, D.4.2

BRMアダプタでの移入, D.3.2

リフレッシュ

集計表, 4.3

データ・マイニング・モデル, 4.3

導出表, 4.3

Oracle Communications Dataウェアハウス, 4.5

レポート

Oracle Communications Data Model, 5.1, 5.3

レポート

アプローチ, 5.1

As Is, 5.6.1

As Was, 5.6.1

パフォーマンスのトラブルシューティング, 5.5

レポート、Oracle Communications Data Model

新規作成, 5.8

S

サンプル・レポート, 5.2

カスタマイズ

Oracle Communications Data Model, 5.2

スキーマ

BRMソース, D.2.2

brm_stg, D.2.2, D.2.3

NCCソース, C.1.1, C.4.1

ncc_stg, C.1.1, C.4.2

ocdm_sys, C.1.1, D.2.2

ステージング, C.4.2, C.4.2.1, D.2.3

サイズ設定

Oracle Communications Data Modelウェアハウス, A.1

Source-ETL

例外処理, 4.2.2.6

ジョブ制御, 4.2.2.5

ロードの考慮事項, 4.2.2.7

Oracle Communications Data Model, 4.1, 4.2, 4.2.2.2, 4.2.2.3, 4.2.2.4, 4.2.2.5, 4.2.2.7

パラレル・ダイレクト・パス・ロード, 4.2.2.7.4

パーティション化, 4.2.2.7.5

アプリケーション・アダプタを使用した作成, 4.2, 4.2.1, 4.5.1

ワークフロー, 4.2.2.5

ステージング・レイヤー, 2.1

Oracle Communications Data Model, 2.1

スター・クエリー, 最適化, 5.4 サブタイプ

表の定義, 2.4.3

物理実装, 2.4.3

スーパータイプ

表の定義, 2.4.3

物理実装, 2.4.3

サロゲート・キー

Oracle Communications Data Model, 2.4.4

T

表

集計, 3.3

圧縮, 2.4.2, 2.4.2.1, 2.4.2.1.1

導出, 3.2

パーティション化, 2.4.7

Oracle Communications Data Modelの表領域, 2.4.1

U

Oracle Communications Dataウェアハウスのアップグレード, E

Oracle Communications Dataウェアハウスのユーザー権限, B

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