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

11gリリース2(11.2)

B72456-01(原本部品番号:E26211-02)

目次

例一覧

図一覧

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

はじめに

- 対象読者

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

- 関連Oracleリソース

- 表記規則

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

- Oracle Airlines Data Modelとは

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

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

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

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

- 実装者の前提知識

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

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

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

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

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

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

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

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

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

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

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

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

- 履歴(_H)表の使用

- ドメイン定義規格

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

- Oracle Airlines Data Modelの基盤レイヤーをカスタマイズする際の一般的な変更シナリオ

- 例: Oracle Airlines Data Modelの基盤レイヤーの変更

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

- Oracle Airlines Data Modelの表領域

- Oracle Airlines Data Modelのデータ圧縮

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

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

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

- Oracle Airlines Data Modelの整合性制約

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

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

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

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

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

- Oracle Airlines Data Modelでのパラレル実行

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

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

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

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

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

- Oracle Airlines Data Modelのディメンション表

- Oracle Airlines Data Modelの導出表

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

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

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

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

- チュートリアル: 顧客生涯価値予測データ・マイニング・モデルのカスタマイズ

- Oracle Airlines Data Modelの集計表

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

- 次元モデルの特性

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

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

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

- OLAP次元モデルの特性

- Oracle OLAPキューブ・ビュー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Oracle Airlines Data ModelのETLのロール

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

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

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

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

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

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

- Source-ETL例外処理の設計

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

- フラット・ファイルのステージング領域の使用

- Source-ETLのRAWデータ・ファイルの準備

- Source-ETLデータ・ロード・オプション

- パラレル・ダイレクト・パス・ロードSource-ETL

- Oracle Airlines Data ModelのSource-ETLのパーティション交換ロード

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

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

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

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

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

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

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

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

- Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表のリフレッシュ

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

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

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

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

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

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

- 実行計画のチェック

- PARALLEL DML実行の監視

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

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

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

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

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

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

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

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

- As Is問合せの特性

- As Was問合せの特性

- 例: As IsおよびAs Was問合せ

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

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

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

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

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

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

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

- Oracle Airlines Data Modelの拡張計画

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

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

索引

例一覧

- 2-1 Oracle Airlines Data Modelの物理データ・モデルの拡張による複数のAIRPORTカテゴリのサポート

- 3-1 create_cust_ltv_svm_rgrsn_modelデータ・マイニング・モデルへの新規列の追加

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

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

- 4-3 ORA-40112のトラブルシューティング: 有効なデータ行数が不足しています

- 4-4 ORA-40113のトラブルシューティング: 個別ターゲット値の数が不足しています

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

- 5-2 スター型変換

- 5-3 Oracle Airlines 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 Airlines Data Modelウェアハウスのレイヤー

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

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

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

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

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

Oracle® Airlines Data Model

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

11gリリース2(11.2)

B72456-01(原本部品番号:E26211-02)

2011年12月

Oracle Airlines Data Model実装およびオペレーション・ガイド11gリリース2 (11.2)

B72456-01

Copyright © 2011, 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 Airlines Data Model実装およびオペレーション・ガイド』では、Oracle Airlines Data Modelに基づいてデータ・ウェアハウスを実装するためのベスト・プラクティスについて説明しています。

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

- 対象読者

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

- 関連Oracleリソース

- 表記規則

対象読者

このドキュメントは、Oracle Airlines 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 Airlines Data Modelを実装する場合の多くのリソースが用意されています。

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

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

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

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

- 『Oracle Airlines 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"内)を名前で検索できます。

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

この章では、Oracle Airlines Data Modelのカスタマイズの概要を示します。この付録には、次の項があります。

- Oracle Airlines Data Modelとは

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

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

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

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

Oracle Airlines Data Modelとは

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

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

Oracle Airlines Data Modelでは、航空会社ビジネス・インテリジェンス・ソリューションに対して行う必要のあるデータ・モデリング作業の多くが提供されます。航空会社のベスト・プラクティスに従って、Oracle Airlines Data Model論理および物理データ・モデルが設計されました。

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

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

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

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

- 第3正規形(3NF)エンティティ・オブジェクト・モデルの論理モデル。論理モデルは、航空業界の標準に従っており、『Oracle Airlines Data Modelリファレンス』に記載されています。

- Oracle Databaseスキーマとして定義される物理モデル。

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

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

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

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

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

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

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

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

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

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

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

- Oracle開発ツール

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

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

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

Oracle開発ツール

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

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

名前

使用

SQL DeveloperまたはSQL*Plus

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

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 Airlines Data Modelで提供された事前定義済のサンプル・ダッシュボード・レポートをカスタマイズできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実装者の前提知識

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

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

- Oracleテクノロジ・スタック、特にデータ・ウェアハウス(データベース、データ・ウェアハウス、OLAP、データ・マイニング、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 Airlines Data Modelをカスタマイズする前に、存在しない場合はデータ・ウェアハウスの管理運営委員会を結成します。この運営委員会の役割は、データ・ウェアハウスを監視し、企業全体に渡って最適なビジネス価値を実現する環境を提供することです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に:

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

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

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

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

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

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

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

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

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

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

Oracle Airlines Data Modelモデルをカスタマイズするには、Oracle Airlines Data Modelコンポーネント間の依存関係、特にレポートKPIが物理表および列にどのようにマップされているかを理解する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- プログラム - 表タブ

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

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

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

- 表 - プログラム・タブ

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

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

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

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

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

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

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

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

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

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

フィットギャップ分析の結果として、航空会社の環境に適するようにOracle Airlines Data Modelをカスタマイズするために必要な適合および調節について簡単に説明するカスタマイズ・レポートが生成されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle Airlines Data Modelのデフォルト物理データ・モデルは、おおよそ次のように定義されます。

370個の表と8,500個の列

220個の業界固有メジャーおよびKPI

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

7個の構築済OLAPキューブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 履歴(_H)表の使用

- ドメイン定義規格

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

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

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

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

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

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

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

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

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

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

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

CB$

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

DMV_

データ・マイニング・モデルのソース・データとして使用されるマテリアライズド・ビュー

DWA_

集計表。

DWB_

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

DWC_

制御表。

DWD_

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

DWL_

検索表。

DWM_

アクセス・レイヤーのファクト表内のディメンション表(つまり、DWD_またはDWA_)。

DWV_

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

DWR_

基盤レイヤーのファクト表内でディメンション表として使用される参照データ表(つまり、DWB_表)。

_H

特定のエンティティの最新データおよび履歴データの両方を格納するために使用される従来のデータ・ウェアハウス表。(「履歴(_H)表の使用」を参照してください。)

_VIEW

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

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

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

履歴(_H)表の使用

デフォルトOracle Airlines Data Modelの物理データ・モデルは、Operational Data Store (ODS)およびデータ・ウェアハウスの両方として機能するように設計されました。この二重の機能をサポートするために、論理エンティティが2つの異なる物理表タイプとして実装されています。

- tablename_H表は従来のデータ・ウェアハウス表です。これらの表は、エンティティの最新データおよび履歴データの両方を格納するために設計されています。これらは、アクセス・レイヤー・オブジェクト(つまり、導出表、集計表およびOLAPキューブ)のデータを提供する表です。_H表に新規データが移入される場合、データは表に追加され、データは上書きされることはありません。

- tablename表は、ODS表です。これらの表は、エンティティの最新データのみを格納するように設計されています。これらは、リアルタイム(または、ほぼリアルタイム)の問合せを行う際にアプリケーションによってアクセスされる表です。これらの表に新規データが移入される場合、新規データによって表内の既存のデータは上書きされます。

たとえば、論理エンティティであるサービスを表す物理表を調べると、DWR_SERVICEとDWR_SERVICE_Hの2つの表があります。DWR_SERVICE表の機能は、最新データを保持することであり、一方、DWR_SERVICE_Hの機能は、最新データと履歴データの両方を保持することです。

ドメイン定義規格

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

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

- 様々な状況の数値。

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

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

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

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

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

- 基盤レイヤー・オブジェクトを変更して論理モデル設計を反映する場合、できるだけ変更は少なくします。「Oracle Airlines Data Modelの基盤レイヤーをカスタマイズする際の一般的な変更シナリオ」は、これに関連して行う最も一般的なカスタマイズ変更の概要を説明しています。

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

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

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

関連項目:
「例: Oracle Airlines Data Modelの基盤レイヤーの変更」

Oracle Airlines Data Modelの基盤レイヤーをカスタマイズする際の一般的な変更シナリオ

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

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

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

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

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

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

関連項目:
「例: Oracle Airlines Data Modelの基盤レイヤーの変更」

例: Oracle Airlines Data Modelの基盤レイヤーの変更

たとえば、Oracle Airlines Data Modelが様々な航空サービスをどのようにサポートするか、サンプルの顧客がフィットギャップ分析中に何を検出するか、およびその顧客が検出されたギャップに合せてOracle Airlines Data Modelをどのように拡張するかを見てみましょう。

航空会社サービスをサポートするエンティティ

航空会社サービスをサポートするOracle Airlines Data Modelの論理モデルに提供されているエンティティは、次のとおりです。

- AIRPORT: 空港(AIRPORT)とは、1つ以上のフライトの出発地または到着地として機能する、IATAによって認識されている場所を指します。このエンティティには、空港のある都市、国、地域など、空港の詳細が格納されます。

- FLIGHT: このエンティティには、フライトの情報(所属する航空会社、フライト番号など)が格納されます。

- AIRCRAFT: このエンティティには、航空機のタイプが格納されます(例: ボーイング737)。

- AIRCRAFT VERSION: このエンティティには、フライトに使用される航空機バージョンの詳細が格納されます。たとえば、航空機タイプがボーイング737の場合、バージョンはボーイング737-800です。

- CARRIER: このエンティティには、航空会社の詳細(航空会社コード、説明など)が格納されます。

- CARRIER TYPE: このエンティティには、航空会社タイプの詳細(航空路線、鉄道、道路輸送、船便など)が格納されます。

フィットギャップ分析中に検出された差異

フィットギャップ分析中に、Oracle Airlines Data Modelで提供されている論理モデルではサポートされない次のニーズが検出されたとします。

- ある会社は、航空分野において複数のサービスを提供しています。言い換えると、その会社では、Oracle Airlines Data Modelの標準論理モデルで表される空港を追跡するだけではなく、空港アクティビティのカテゴリ(つまり、空港カテゴリ)別に空港を定義する必要もあります。たとえば、これらの空港カテゴリは、商業サービス空港、主要空港、貨物サービス空港、救援空港、一般航空空港などです。

- 航空業務において、航空会社は、様々なサービスを運用するために使用する空港カテゴリ(商業、貨物、救援または一般空港など)の履歴を管理する必要があります。

差異をサポートするための論理および物理モデルの拡張

差異をサポートするには、次の方法で論理および物理モデルを拡張する必要があります。

- 空港カテゴリの詳細を格納するには、論理モデルを変更する必要があります。これを行う従来の方法は、この情報を保持する別のエンティティを追加することです。たとえば、AIRPORTエンティティと1:M関係を持つAIRPORT CATEGORYという名前のエンティティを追加できます。次に、対応する方法で物理データ・モデルを拡張します。物理モデルを拡張する手順の詳細は、例2-1「Oracle Airlines Data Modelの物理データ・モデルの拡張による複数のAIRPORTカテゴリのサポート」に示されています。

- 各空港カテゴリから行われる航空業務の履歴を管理するには、対応する区間エンティティのフライト・スケジュールとAIRPORTエンティティ間の既存の関係に基づいて同じものを見つけられます。

例2-1 Oracle Airlines Data Modelの物理データ・モデルの拡張による複数のAIRPORTカテゴリのサポート

Oracle Airlines Data Modelの基盤レイヤーの設計を拡張し、複数のAIRPORTカテゴリをサポートするには、次の手順を実行します。

1. 次の文を実行して、空港の複数カテゴリ情報を保持するためのDWL_ARPRT_CTGRSという名前の新しい表を作成します。

CREATE TABLE DWL_ARPRT_CTGRS
(
ARPRT_CTGRS_ID          INTEGER NOT NULL ,
ARPRT_CTGRS_NM          VARCHAR2(50) NULL ,
ARPRT_CTGRS_DESC        VARCHAR2(500) NULL ,
ARPRT_CTGRS_CD          CHAR(18) NULL ,
DWFEED_ID               INTEGER NULL ,
SRC_SYS_ID              VARCHAR2(30) NULL ,
SRC_SYS_CRTD_TMSTMP     TIMESTAMP NULL ,
SRC_SYS_UPD_TMSTMP      TIMESTAMP NULL ,
SRC_SYS_DEL_IND         VARCHAR2(1) NULL
);

ALTER TABLE DWL_ARPRT_CTGRS    ADD CONSTRAINT  XPKARPRT_CTGRS PRIMARY KEY (ARPRT_CTGRS_ID);

2. 次の文を実行して、DWL_ARPRT_CTGRSの履歴情報を保持するDWL_ARPRT_CTGRS_Hという名前の新しい表を作成します。

CREATE TABLE DWL_ARPRT_CTGRS_H
(
ARPRT_CTGRS_ID          INTEGER NOT NULL ,
ARPRT_CTGRS_NM          VARCHAR2(50) NULL ,
ARPRT_CTGRS_DESC        VARCHAR2(500) NULL ,
ARPRT_CTGRS_CD          CHAR(18) NULL ,
DWFEED_ID               INTEGER NULL ,
SRC_SYS_ID              VARCHAR2(30) NULL ,
SRC_SYS_CRTD_TMSTMP     TIMESTAMP NULL ,
SRC_SYS_UPD_TMSTMP      TIMESTAMP NULL ,
SRC_SYS_DEL_IND         VARCHAR2(1) NULL ,
ETL_BATCH_ID            INTEGER NULL ,
ETL_BATCH_CRTD_BY       VARCHAR2(60) NULL ,
ETL_BATCH_CRTD_TMSTMP   TIMESTAMP NULL ,
ETL_BATCH_UPD_BY        VARCHAR2(60) NULL ,
ETL_BATCH_UPD_TMSTMP    TIMESTAMP NULL ,
DATA_MVT_STS_CD         VARCHAR2(25) NULL ,
VLD_FRM                 TIMESTAMP NULL ,
VLD_UPTO                TIMESTAMP NULL ,
CURR_STS                VARCHAR2(1) NULL ,
DWL_ARPRT_CTGRS_H_SKEY  INTEGER NOT NULL
);

3. 次の文を発行して、ARPRT_CTGRS_IDという名前の列をDWR_AIP表に追加します。

ALTER TABLE DWR_AIP ADD COLUMN ARPRT_CTGRS_ID INTEGER NULL;

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

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

- Oracle Airlines Data Modelの表領域

- Oracle Airlines Data Modelのデータ圧縮

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

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

- Oracle Airlines Data Modelの整合性制約

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

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

- Oracle Airlines Data Modelでのパラレル実行

Oracle Airlines Data Modelの表領域

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

推奨: 表領域の定義

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

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

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

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

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

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

ALTER TABLE table_name MODIFY DEFAULT ATTRIBUTES
TABLESPACE new_tablespace_name;

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

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

ALTER TABLE table_name MOVE TABLESPACE new_tablespace_name;

Oracle Airlines Data Modelのデータ圧縮

実行する必要がある主な決定は、データを圧縮するかどうかです。表の圧縮を使用すると、ディスクおよびメモリーの使用率が削減され、多くの場合に読取り専用操作のスケールアップ・パフォーマンスが向上します。また、表の圧縮は、ディスクのデータの取得に必要なラウンド・トリップの数を最小化して、問合せ実行を高速化できます。ただし、データの圧縮は、データのロード速度でパフォーマンスが低下します。Oracle Airlines 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 Airlines Data Modelは、すべての実表、導出表および集計表に圧縮機能を利用します。これにより、格納されるデータ量とメモリー使用率が削減され(メモリー・ブロック当たりのデータが増えます)、問合せのパフォーマンスが向上します。

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

alter table <tablename> move 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 Airlines Data Modelのスーパータイプおよびサブタイプ・エンティティの表

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

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

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

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

たとえば、デフォルトのOracle Airlines Data Modelでは、表DWB_PRTY_INTRATN (パーティ・インタラクション)は、DWB_PRTY_INTRATN_CALL (パーティ・インタラクション - 電話)およびDWB_PRTY_INTRATN_EML (パーティ・インタラクション - 電子メール)を含む多くのサブタイプを持つスーパータイプです。

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

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

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

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

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

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

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

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

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

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

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

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

- 番号変更処理

- 重複する範囲

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

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

- ETL中の割当てが必要

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

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

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

Oracle Airlines Data Modelの整合性制約

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結合パフォーマンスのためのOracle Airlines 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 Airlines Data Modelでのパラレル実行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パラレル問合せは、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 Airlines Data Modelのアクセス・レイヤーのカスタマイズについて説明します。内容は次のとおりです。

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

- Oracle Airlines Data Modelのディメンション表

- Oracle Airlines Data Modelの導出表

- Oracle Airlines Data Modelの集計表

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

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

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

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

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

oadm_sysスキーマのアクセス・レイヤー・オブジェクトには、導出表および集計表、導出表および集計表のディメンションを提供する表、OLAPキューブ、およびマテリアライズド・ビューが含まれます。このレイヤーには、データ・マイニング・モデルも含まれます。これらのモデルの結果が導出表に格納されます。

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

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

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

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

- Oracle Airlines Data Modelのディメンション表

- Oracle Airlines Data Modelの導出表

- Oracle Airlines Data Modelの集計表

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

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

Oracle Airlines Data Modelのディメンション表

ディメンション表は、ファクト表のディメンション・データを格納する表です。Oracle Airlines Data Modelには、他の表に対してディメンションとして機能する2つのタイプの表があります。

- 基盤レイヤーでは、DWR_表(参照表とも呼ばれる)は、実表(DWB_)へのディメンション表として機能します。

- アクセス・レイヤーでは、DWM_表(単純にディメンション表と呼ばれる)は、導出表(DWD_)および集計表(DWA_)へのディメンション表として機能します。DWM_表は、スター・スキーマのディメンション表で示されるビューと同様のデータのビューを提供します。

デフォルトOracle Airlines Data Modelは、いくつかのディメンション表を定義します。たとえば、DWR_SEGおよびDWM_SEG表は、様々なレイヤーのセグメント情報の値を格納します。

Oracle Airlines Data Modelの導出表

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

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

- 計算結果を保持する表。これらの表のカスタマイズの詳細は、「計算データの新しい導出表の作成」を参照してください。

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

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

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

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

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

oadm_sysスキーマで定義されている導出表(DWD_)の一部は、Oracle Airlines Data Modelで定義されているデータ・マイニング・モデルの結果表です。すべてのOracle Airlines Data Modelデータ・マイニング・モデルは、マテリアライズド・ビューをソース入力として使用します。これらのマテリアライズド・ビューは、$ORACLE_HOME/oadm/pdm/miningにあるoadm_mining_init.sqlスクリプトで定義されます。異なるデータ・マイニング・モデルは異なるソース・マテリアライズド・ビューを使用します。

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

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

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

関連項目:
「チュートリアル: 顧客生涯価値予測データ・マイニング・モデルのカスタマイズ」

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

新しいデータ・マイニング・モデルを作成するには、次の手順を実行します。

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

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

3. データ・マイニング・モデルに必要な物理表をoadm_sysスキーマに追加します。データ・マイニング・ソース表に名前を付ける際は、接頭辞DM_を使用します。データ・マイニング結果表に名前を付ける際は、接頭辞DWD_を使用します。

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

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

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

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

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

例3-1 create_cust_ltv_svm_rgrsn_modelデータ・マイニング・モデルへの新規列の追加

create_cust_ltv_svm_rgrsn_modelデータ・マイニング・モデルでは、dmv_cust_ltv_srcマテリアライズド・ビューがソース入力として使用されます。新規列をcreate_cust_ltv_svm_rgrsn_modelデータ・マイニング・モデルに追加してモデルをカスタマイズするには、次の手順を実行します。

1. 次のマテリアライズド・ビューを変更します。

- dmv_bkg_fact_src

- dmv_lylty_acct_bal_src

- dmv_cust_profile_src

2. 顧客生涯価値回帰データ・マイニング・モデルをトレーニングし、次の文を実行します。
pkg_oadm_mining.create_cust_ltv_svm_rgrsn

3. 次の文を発行して結果表を問い合せて、新しい列名が問合せ結果に含まれていることを確認します。
SELECT attribute_name FROM TABLE( SELECT attribute_set FROM TABLE(DBMS_DATA_MINING.GET_MODEL_DETAILS_SVM('CUST_LTV_SVM_RGRSN')));

関連項目:
「Oracle Airlines Data Modelデータ・マイニング・モデルのリフレッシュ」および「データ・モデル・マイニング作成のトラブルシューティング」。

チュートリアル: 顧客生涯価値予測データ・マイニング・モデルのカスタマイズ

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

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

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

このチュートリアルでは、Oracle Airlines Data ModelマイニングAPIを使用して、顧客生涯価値予測モデルを調査する方法を示します。トレーニング・プロセスで様々なパラメータを使用する、またはより高度な方法でモデルをカスタマイズするには、マイニング設定表(接頭辞がDM_)を変更するか、Oracle Data Miner GUIツールを使用できます。

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

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

- 環境の準備

- モデルの生成

- 結果のチェック

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

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

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

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

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

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

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

DWB_LYLTY_ACCT_BAL_HIST_H
DWD_BKG_FACT
DWM_CLNDR
DWM_FRQTFLR
DWM_GEOGRY

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

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

2. サンプル・データ(oadm_sample_mining.dmp.zip)をダウンロードして、新しいoadm_sysスキーマにデータをインポートします。

環境の準備

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

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

1. SQL Developerで、oadm_sysスキーマに接続します。

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

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

2. oadm_sysスキーマに接続したら、作成済のすべての表を表示できます。「表」を右クリックしてフィルタを適用し、リストを絞り込むことができます。

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

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

grant dba to oadm_sys

2. チュートリアルで必要な表のすべての外部キーを無効にします。
まず、SQL文を生成する次の文を発行します。

SELECT 'ALTER TABLE ' || table_name || ' DISABLE CONSTRAINT ' ||
CONSTRAINT_NAME ' CASCADE;' FROM all_constraints
WHERE status='ENABLED' AND owner='OADM_SYS'
AND constraint_type=
'R' and table_name IN
('DWB_LYLTY_ACCT_BAL_HIST_H','DWD_BKG_FACT','DWM_CLNDR',
'DWM_FRQTFLR','DWM_GEOGRY') ;

次に、次の表の外部キーを実際に無効にするために、前のSELECT文で生成されたSQL文を実行します。

DWB_LYLTY_ACCT_BAL_HIST_H
DWD_BKG_FACT
DWM_CLNDR
DWM_FRQTFLR
DWM_GEOGRY

3. サンプル・ダンプ(oadm_sample.dmp)が、デフォルトのデータ・ダンプ・ディレクトリ(DATA_PUMP_DIR)にあることを確認します。次に、次の文を発行して、サンプル・マイニング・ダンプをoadm_sysスキーマにインポートします。(passwordの部分は、oadm_sysのパスワードに置き換えてください。)

impdp oadm_sys/password directory=DATA_PUMP_DIR dumpfile=oadm_sample.dmp
content=DATA_ONLY table_exists_action=truncate
TABLES=oadm_sample.DWB_LYLTY_ACCT_BAL_HIST_H,
oadm_sample.DWD_BKG_FACT,oadm_sample.DWM_CLNDR,
oadm_sample.DWM_FRQTFLR,oadm_sample.DWM_GEOGRY

4. 有効なデータ(固有の顧客データまたはサンプル・マイニング・データのいずれか)が含まれている表を確認します。

5. Oracle Airlines Data ModelマイニングAPI内のモデル・プロシージャを実行する前に、マイニング結果表DWD_CUST_MNNGが空であることを確認します。

モデルの生成

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

- すべてのマイニング・ソース・マテリアライズド・ビューをリフレッシュするpkg_oadm_mining.refresh_mining_source。

- 顧客生涯価値予測モデルを生成するpkg_oadm_mining.create_cust_ltv_svm_rgrsn。

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

1. 次のSQL文を実行して、Oracle Airlines Data Modelマイニング・ソース・マテリアライズド・ビューをリフレッシュします。

SELECT count(*) FROM dmv_cust_ltv_src;
exec pkg_oadm_mining.refresh_mining_source;
SELECT count(*)FROM dmv_cust_ltv_src;

次の文を実行します。

1. マテリアライズド・ビューのリフレッシュの前に、dmv_cust_ltv_srcマテリアライズド・ビューのレコード数を表示します。

2. マイニング・ソース・マテリアライズド・ビューをリフレッシュします。

3. マテリアライズド・ビューのリフレッシュの後に、dmv_cust_ltv_srcマテリアライズド・ビューのレコード数を表示します。

2. 次の文を実行して、顧客生涯価値予測モデルを生成します。

SELECT count(*) FROM dwd_cust_mnng;
SELECT count(*) FROM dwd_cust_ltv_svm_factor;
EXEC pkg_oadm_mining. create_cust_ltv_svm_rgrsn;
SELECT count(*) FROM dwd_cust_mnng;
SELECT count(*) FROM dwd_cust_ltv_svm_factor;

次の文を実行します。

1. データ・マイニング・モデルの構築の前に、dwd_cust_mnng表のレコード数を表示します。

2. データ・マイニング・モデルの構築の前に、dwd_cust_ltv_svm_factor表のレコード数を表示します。

3. データ・マイニング・モデルをトレーニングします。

4. データ・マイニング・モデルの構築の後に、dwd_cust_mnng表のレコード数を表示します。

5. データ・マイニング・モデルの構築の後に、dwd_cust_ltv_svm_factor表のレコード数を表示します。

結果のチェック

マイニング・ソースのマテリアライズド・ビューをリフレッシュし、データ・マイニング・モデルを構築した後、次の手順に示すように、dwd_cust_mnng表内のマイニング予測結果を確認します。

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

SELECT frqtflr_card_key, ltv_value, ltv_band_cd FROM dwd_cust_mnng;

2. frqtflr_card_keyで識別される顧客ごとに、ltv_value列で顧客生涯価値(連続値)の予測が示されます。予測値ltv_valueをビニングすることで、ltv_band_cd列に値が移入されます。

Oracle Airlines Data Modelの集計表

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

デフォルトのOracle Airlines Data Modelは、複数の集計表を定義しています。たとえば、DWA_DLY_BKG_FACT表は、DWD_BKG_FACT表の値を1日、セグメントおよびトラフィック・カテゴリ・レベルで集計します。

参照:
デフォルトOracle Airlines Data Modelのすべての集計表のリストは、『Oracle Airlines Data Modelリファレンス』の集計表に関する項を参照してください。

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

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

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

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

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

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

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

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

- 次元モデルの特性

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

- OLAP次元モデルの特性

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

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

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

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

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

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

次元モデルの特性

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

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

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

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

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

- ディメンション。ディメンションは、ユーザーのビジネス上の疑問に答えられるようにデータを分類する構造です。一般的に使用されるディメンションは、Account、Airport、Flight、GeographyおよびCalendarです。ディメンションの構造は、親子リレーションシップに基づいて階層的に編成されます。これらのリレーションシップで次のことが可能です。

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

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

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

- 計算用のメンバーのグループ化。
シェアおよび指標計算では、階層リレーションシップ(たとえば、利用頻度の高い各乗客メンバー・レベルが寄与する合計チケット予約数の割合、特定のセグメントの飛行収益のシェア割合、販売代理店の場所の地理的地域の割合としての売上収益など)を利用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:
デフォルトのOracle Airlines Data Modelでは、ディメンション表として使用されるリレーショナル表は、CREATE DIMENSIONコマンドを使用して定義されていません。

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

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

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

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

注意:
デフォルトのOracle Airlines Data Modelで提供されている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 Airlines Data Modelの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で、oadm_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 Airlines Data ModelのOLAPキューブの特性

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

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

- すべてのデフォルトのOLAPキューブは、DWA_表のデータとともにロードされます。

- Analytical Workspace Manager(AWM)クライアント・ツールを使用して、キューブが定義および作成されました。

- リレーショナル・ビュー(_VIEW接尾辞を使用)は、各OLAPキューブに定義されます。

- Oracle Airlines Data ModelのすべてのOLAPキューブは、キューブのマテリアライズド・ビューとして有効化できる状態にあります(つまり、CB$オブジェクト)。

ヒント:
インストールの直後に、OLAPキューブの基になるすべてのマテリアライズド・ビューがデフォルトで無効になります。キューブ・マテリアライズド・ビューを有効にするには、「マテリアライズド・ビュー機能の追加」で概説する手順に従う必要があります。

Oracle Airlines Data ModelのカスタマイズしたバージョンのOLAPキューブの使用の詳細は、『Oracle OLAPユーザーズ・ガイド』および次のトピックを参照してください。

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

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

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

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

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

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

新しいOLAPキューブをoadm_sysスキーマに追加できます。一貫性のため、「Oracle Airlines Data ModelのOLAPキューブの特性」の説明に従って、これらの新しいキューブを設計および定義します。

次の手順を実行して、新しいキューブを定義します。

1. キューブの「最下位のリーフ」データとして使用する集計表(DWA_)があることを確認します。新しい表の作成の詳細は、「Oracle Airlines Data Modelの集計表」を参照してください。

2. AWMを使用して、Oracle Airlines Data Modelのカスタマイズしたバージョンの新しいキューブを定義します。『Oracle OLAPユーザーズ・ガイド』のキューブおよびディメンションを作成する指示に従います。
新しいOLAPキューブを設計および定義する場合、「OLAP次元モデルの特性」で提供されている情報および『Oracle OLAPユーザーズ・ガイド』を使用します。また、「リレーショナル・スターおよびスノーフレーク表の特性」で概説するリレーショナル・スター・スキーマ設計に慣れている場合、この知識を利用して、次に説明するようにOLAPキューブを設計できます。

- ファクト表は、キューブに対応する。

- ファクト表のデータ列は、メジャーに対応する。

- ファクト表の外部キー制約は、ディメンション表に対応する。

- ディメンション表は、ディメンションに対応する。

- ディメンション表の主キーは、ベース・レベルのディメンション・メンバーに対応する。

- ディメンション表の親列は、上位レベルのディメンション・メンバーに対応する。

- ディメンション・メンバーの説明や特性が格納されているディメンション表の列は、属性に対応する。

また、Oracle Airlines Data Modelに含まれるサンプル・レポートを参照して、次元モデルを理解できます。

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

ヒント:
ソース・データを調査するときに、作成しようとしている次元モデルとの一致度がより高いリレーショナル・ビューを作成することもできます。

3. 「マテリアライズド・ビュー機能の追加」の説明に従って、マテリアライズド・ビュー機能をOLAPキューブに追加します。

関連項目:
『Oracle OLAPユーザーズ・ガイド』、「Oracle Airlines Data Modelの新しいOracle OLAPキューブの定義」および『Oracle Airlines Data Modelリファレンス』のサンプル・レポート

Oracle By Example:
OLAPキューブの作成の詳細は、OLAP 11gキューブの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

Oracle Airlines Data ModelのOracle OLAPキューブの変更

Oracle Airlines Data Modelキューブの一般的なカスタマイズは、キューブのディメンションまたはメジャーを変更します。

すべてのOracle Airlines Data Modelキューブは接頭辞がDWA_の表からデータをロードするため、1つのキューブのメジャーまたはディメンションを変更する場合は、次の手順に従う必要があります。

1. 『Oracle Airlines Data Modelリファレンス』の情報を使用して、OLAPキューブの移入元のDWA_表を識別します。

2. 手順1で識別したDWA_表の構造を変更します。

3. OLAPキューブとキューブ・マテリアライズド・ビューを変更して、新しい構造を反映します。

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

Oracle Airlines Data Modelの予測キューブを作成する手順は、次のとおりです。

1. 「Oracle Airlines Data Modelの新しいOracle OLAPキューブの定義」の説明に従って、予測の結果を含むキューブを作成します。

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

2. 『Oracle OLAP DMLリファレンス』の説明に従って、OLAP DML予測コンテキスト・プログラムを作成します。

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

パーティション化は物理的にキューブの内容を格納する方法です。これによって、大きいキューブのパフォーマンスが次のように向上します。

- データ構造をコンパクトに保つことで、スケーラビリティが向上します。各パーティションは、小さなメジャーのように機能します。

- 関連するデータはまとめて格納されるため、問合せまたはメンテナンスの際に対象となるデータセットが小さくて済みます。

- データ・メンテナンス時のパラレル集計が可能になります。各パーティションを別々のプロセスで集計できます。

- 記憶域上の古いデータの削除が容易になります。古いパーティションを削除し、新しいパーティションを追加できます。

パーティションの数は、キューブへのデータのロードやデータの集計に割当て可能なデータベース・リソースに影響します。十分なリソースが割り当てられていれば、複数のパーティションを同時に集計できます。

ソース表の分析とパーティション化方法の決定は、キューブ・パーティショニング・アドバイザによって行われます。キューブ・パーティショニング・アドバイザの推奨する方法を採用できますが、ユーザー独自のパーティション化方法を決めることもできます。

パーティション化戦略が主にライフサイクル管理を考慮して作成される場合は、時間ディメンションでキューブをパーティション化する必要があります。こうすれば、古い期間をまとめて削除し、新しい期間を新しいパーティションに追加できます。キューブ・パーティショニング・アドバイザの時間オプションを選択すると、Timeディメンションの階層とレベルをパーティション化に使用するよう推奨されます。

キューブをパーティション化するレベルは、ロード・パフォーマンスと問合せパフォーマンスのトレードオフに基づいて決定されます。

通常、非常に低いレベル(たとえば、時間ディメンションの日レベルなど)ではパーティション化しません。実行すると、非常に多くのパーティションをロード時に定義する必要があり、初期ロードまたは履歴ロードの速度が低下するためです。また、多数のパーティションの結果、アナリティック・ワークスペース接続時間が異常に長くなり、時系列ベースの計算の速度が低下する場合があります。また、四半期累積メジャー(現在までの1四半期メジャー)は、90または91のパーティションにアクセスして、1つの顧客および組織の特定の値を計算する必要があります。パーティション・ディメンションのパーティション・レベルより上位のすべてのディメンション・メンバー(デフォルト以外の階層に属するメンバーを含む)は、単一のデフォルトのテンプレートに存在します。すべての上位レベルのメンバーがデフォルトのテンプレートに格納されるため、日レベルのパーティション化は非常に重くなります。ただし、OLAPキューブ・ロード頻度が日単位の場合のDAYのパーティション化の利点は、毎日ファクト表の新しいパーティションからOLAPキューブの単一のパーティションにロードするだけで済むことです。これにより、キューブがマテリアライズド・ビュー対応でマテリアライズド・ビュー・ログを含む場合に割合ベースのリフレッシュを有効にできるので、ロード・パフォーマンスが大幅に向上します。

推奨: キューブ・パーティション化戦略

通常、異なるロードと問合せパフォーマンス要件の適切な妥協案として、パーティション・レベルとしてMONTHなどの中間レベルを使用します。月内の時系列計算(現在までの週、現在までの月など)は高速で、現在までの年などの上位レベルの計算は最大で12のパーティションを参照する必要があります。また、このように、月単位のパーティションが各月の最初の初期ロード中に一度だけ定義および作成され、その月の後続のロードのたびに再使用されます。集計プロセスが特定の日レベルのかわりに月レベルでトリガーされ、現在の月の以前にロードした日の余分な集計が毎回発生する可能性がありますが、結果は正常なロードおよび問合せパフォーマンスになります。

関連項目:
パーティション戦略の選択の説明は、『Oracle OLAPユーザーズ・ガイド』、「Oracle Airlines Data Modelの索引とパーティション索引」および「パーティション化とマテリアライズド・ビュー」を参照してください。

Oracle Airlines 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 Airlines Data Modelのマテリアライズド・ビュー

マテリアライズド・ビューは、スキーマ・オブジェクトとして事前に格納またはマテリアライズされた問合せ結果です。物理設計の観点からすると、マテリアライズド・ビューは表やパーティション表に似ており、透過的に使用されパフォーマンスが向上するという点で、索引のような動作をします。

以前は、サマリーを使用する場合、手動でのサマリーの作成、どのサマリーを作成するかの識別、サマリーへの索引付け、サマリーの更新、およびユーザーに対するサマリーのアドバイスに膨大な時間と労力を費やしていました。マテリアライズド・ビューの導入で、データベース管理者はサマリーと同等の1つ以上のマテリアライズド・ビューを作成します。そのため、データベース管理者の作業負荷が軽減され、ユーザーはどのサマリーが定義されているかを把握する必要がなくなっています。かわりに、エンド・ユーザーは、表やビューをディテール・データ・レベルで問い合せます。Oracleサーバーのクエリー・リライト・メカニズムにより、サマリー・テーブルを使用するようにSQL問合せが自動的にリライトされ、問合せから結果を戻すレスポンス時間が短縮されます。

マテリアライズド・ビューは、問合せを実行する前にコストの高い結合および集計操作をデータベース上で事前に計算し、その結果をデータベースに格納することで、問合せのパフォーマンスを改善します。問合せオプティマイザでは、問合せの要求を満たすのに既存のマテリアライズド・ビューが使用可能かどうか、また必要かどうかが自動的に認識されます。

デフォルトのOracle Airlines Data Modelは、マテリアライズド・ビューを定義します。デフォルトのoadm_sysスキーマでは、次の表にリストされている接頭辞を使用したオブジェクトを参照して、これらのマテリアライズド・ビューを識別できます。

接頭辞

説明

CB$

マテリアライズド・ビュー機能で拡張されるOLAPキューブ。
参照: デフォルトのデータ・モデルのこれらのオブジェクトのリストは、『Oracle Airlines Data Modelリファレンス』のOLAPキューブ・マテリアライズド・ビューを参照してください。

OLAPキューブの詳細は、「Oracle Airlines Data ModelのOLAPキューブの特性」を参照してください。

注意: これらのオブジェクトのレポートまたは問合せを実行しないでください。かわりに、OLAPキューブのリレーショナル・ビュー(つまり、_VIEW接尾辞を使用したオブジェクト)にアクセスします。

DMV_

データ・マイニング・ソース・マテリアライズド・ビュー。
参照: デフォルトのデータ・モデルのこれらのオブジェクトを確認するには、『Oracle Airlines Data Modelリファレンス』を参照してください。

次のトピックで、カスタマイズしたOracle Airlines Data Modelのマテリアライズド・ビューの使用および作成の詳細を説明します。

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

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

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

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

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

リフレッシュ・オプションは、マテリアライズド・ビューのタイプごとに異なります。

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

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

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

参照:
Oracle OLAPキューブのマテリアライズド・ビューの作成の詳細は、『Oracle OLAPユーザーズ・ガイド』を参照してください。

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

データ・ウェアハウスで、通常マテリアライズド・ビューは集計を含みます。デフォルトのOracle Airlines 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パラメータを指定すると、適切な依存順序でネステッド・マテリアライズド・ビューのツリーをリフレッシュできます。

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

マテリアライズド・ビューに対して行う最も一般的な操作は、問合せの実行および高速リフレッシュですが、各操作には、異なるパフォーマンス要件があります。

- 問合せの実行では、マテリアライズド・ビュー・キー列のすべてのサブセットがアクセスされる必要があり、これらの列のサブセット上で結合および集計が行われる必要がある場合があります。したがって、最適なパフォーマンスには、各マテリアライズド・ビュー・キー列上に単一列のビットマップ索引を作成します。

- 結合のみを含むマテリアライズド・ビューに高速リフレッシュ・オプションを使用する場合は、ROWIDを含む列上に索引を作成して、リフレッシュ操作のパフォーマンスを向上させます。

- 集計を使用するマテリアライズド・ビューが高速リフレッシュ可能な場合は、CREATE MATERIALIZED VIEW文にUSING NO INDEXが指定されていないかぎり、高速リフレッシュ・プロシージャに適切な索引が作成されます。

関連項目:
「Oracle Airlines Data Modelの索引とパーティション索引」

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

データ・ウェアハウスに格納されているデータの量は膨大であるため、パーティション化は、データベースの設計時に非常に有効なオプションです。ファクト表のパーティション化によって、スケーラビリティの向上とシステム管理の簡素化を実現できます。また、効率的に再作成できるローカル索引を定義できるようになります。ファクト表をパーティション化することにより、マテリアライズド・ビューに対するパーティション・チェンジ・トラッキング・リフレッシュが可能になるので、マテリアライズド・ビューを高速リフレッシュできる可能性も高くなります。

マテリアライズド・ビューのパーティション化は、ファクト表のパーティション化と同じ利点があります。マテリアライズド・ビューがパーティション化されると、リフレッシュ・プロシージャは、より多くの場合にパラレルDMLを使用でき、パーティション・チェンジ・トラッキング・ベースのリフレッシュは、パーティションの切捨てを使用してマテリアライズド・ビューを効率的にメンテナンスできるようになります。

関連項目:
『Oracle Database VLDBおよびパーティショニング・ガイド』、「Oracle Airlines Data Modelのパーティション表」、「Oracle Airlines Data Model内の索引およびパーティション化された索引」および「Oracle Airlines 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 Airlines Data Modelのデータ圧縮」および「Oracle Airlines Data Modelの集計表」

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

この章では、Oracle Airlines Data Modelウェアハウスを移入するために使用するETL(抽出、変換およびロード)プログラムについて説明します。内容は次のとおりです。

- Oracle Airlines Data ModelのETLのロール

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

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

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

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

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

Oracle Airlines Data ModelのETLのロール

図2-1「Oracle Airlines Data Modelウェアハウスのレイヤー」は、Oracle Airlines Data Modelウェアハウスの3つのレイヤー、オプションのステージング・レイヤー、基盤レイヤーおよびアクセス・レイヤーを示しています。2つのタイプのETL(抽出、変換およびロード)を使用して、これらのレイヤーを移入します。

- Source-ETL。ステージング・レイヤー(存在する場合)および基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、ソースETLと呼ばれます。
Oracle Airlines Data Modelは、Source-ETLスクリプトを含みません。使用しているのOLTPシステムを理解し、カスタマイズしたOracle Airlines Data Modelを使用して、自分でSource-ETLを作成する必要があります。Source-ETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。

- Intra-ETL。基盤レイヤーのデータを使用してアクセス・レイヤー(つまり、導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)を移入するETLは、Intra-ETLと呼ばれます。
Oracle Airlines Data Modelは、Intra-ETLを含みます。デフォルトのIntra-ETLを変更して、カスタマイズした基盤レイヤーからカスタマイズしたアクセス・レイヤーに移入できます。Intra-ETLの詳細は、「Oracle Airlines Data ModelのIntra-ETLのカスタマイズ」を参照してください。

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

Oracle Airlines Data Modelウェアハウスの基盤レイヤー(つまり、実表、参照表および検索表)にOLTPシステムのデータを移入するETLは、Source-ETLと呼ばれます。

Oracle Airlines Data Modelウェアハウスの基盤レイヤーに移入するには、Oracle Warehouse Builderまたは別のETLツールを使用して固有のSource-ETLスクリプトを書き込み、それらのスクリプトを使用して基盤レイヤーに移入します。

次のトピックでは、Source-ETLの書込みの一般的な情報について説明します。

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

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

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

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

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

- Source-ETL例外処理の設計

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

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

Oracle Airlines Data ModelのSource-ETLを設計および作成するときは、次の点に注意してください。

- Oracle Airlines Data Modelで提供され、『Oracle Airlines Data Modelリファレンス』で説明されているカレンダ移入スクリプトを使用してカレンダ・データを移入できます。

- 表は次の順序で移入します。

1. 検索表

2. 参照表

3. 実表

- 1つのカテゴリの表を分析してから、次のカテゴリの表をロードします(たとえば、参照表をロードする前に検索表を分析します)。また、Intra-ETLプロセスを実行する前に、Source-ETLでロードされたすべての表を分析する必要があります。

参照:
『Oracle Database管理者ガイド』の表、索引およびクラスタの分析に関するトピック。

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

ETLは、最初に元のソースからデータを抽出し、データの品質を確認して、元のソースのデータを一貫性のある状態にします。ETLは、問合せツール、レポート・ライター、ダッシュボードなどでデータにアクセスするため、物理オブジェクトに「クリーンな」データを移入します。

データの取得が行われる基本サービスは、次のとおりです。

- データ・ソーシング

- データ移動

- データ変換

- データのロード

論理アーキテクチャの観点から、データ取得サービスを提供するためにこれらの構築ブロックを構成する多くの異なる方法があります。データ・ウェアハウス・アーキテクチャ内を対象とする幅広いオプションを含む使用できる主要なアーキテクチャ・スタイルは、次のとおりです。

- バッチ抽出、変換およびロードとバッチ抽出、ロード、変換、ロード
バッチ抽出、変換およびロード(ETL)およびバッチ抽出、ロード、変換、ロード(ELTL)は、データ・ウェアハウス実装の従来のアーキテクチャです。これらの違いは、変換がデータベースの内部または外部で発生するかどうかです。

- バッチ・ハイブリッド抽出、変換、ロード、変換、ロード
バッチ・ハイブリッド抽出、変換、ロード、変換、ロード(ETLTL)は、ハイブリッド戦略です。この戦略は、変換設計に対するハンド・コーディング・アプローチを排除してメタデータドリブン・アプローチを適用する最も高い柔軟性を提供し、エンタープライズ・ウェアハウスのデータ処理機能を引き続き利用できます。このターゲットの設計では、ステージング表をロードする前の事前処理の手順として、変換処理がウェアハウスの外部で最初に実行され、サーゲット表に最後にロードする前に追加の変換処理がデータ・ウェアハウスの内部で実行されます。

- リアルタイム抽出、変換、ロード
最新のデータのサービス・レベルでデータ・ウェアハウス環境の詳細な更新情報を要求する場合、リアルタイム抽出、変換、ロード(rETL)が適切です。このアプローチでは、rETLプロセスが適宜メッセージ・バス(キュー)から抽出するため、OLTPシステムで任意のイベントをアクティブに公開する必要があります。メッセージ・ベース・パラダイムは、公開およびサブスクライブ・メッセージ・バス構造または信頼性のあるキューのポイントツーポイント・メッセージングとともに使用します。

Oracle Airlines 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 Airlines 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 Golden Gateなど)

- システムおよびメインフレームを開く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 Airlines Data ModelのSource-ETLのパーティション交換ロード

パーティション化の利点は、EXCHANGE PARTITIONコマンドを使用してビジネス・ユーザーの影響を最小限にデータを迅速かつ容易にロードする機能です。EXCHANGE PARTITIONコマンドは、パーティション化されていない表のデータをパーティション化された表の特定のパーティションにスワップできます。EXCHANGE PARTITIONコマンドは物理的にデータを移動しません。かわりに、データ・ディクショナリを更新してパーティションおよび表のポインタを交換します。

データの物理的な移動がないため、交換はREDOおよびUNDOを生成しません。つまり、交換は1秒以内の処理で、INSERTなどの従来のデータ移動アプローチよりもパフォーマンスへの影響が大幅に少なくなります。

推奨: 表のパーティション化

Oracle Airlines Data Modelウェアハウスの大きい表およびファクト表をパーティション化します。

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

日単位でレンジ・パーティション化されるDWB_PNR_Hという大きい表があるとします。各営業日の最後に、オンライン航空会社システムのデータがウェアハウスのDWB_PNR_H表にロードされます。

次の手順により、日単位のデータがデータ・ウェアハウスのビジネス・ユーザーへの影響を最小限に最適な速度で正しいパーティションにロードされます。

1. オンライン・システムから取得するフラット・ファイル・データの外部表を作成します。

2. CTAS文を使用して、DWB_PNR_H表と同じ列構造を持つtmp_pnrというパーティション化されていない表を作成します。

3. tmp_pnr表のDWB_PNR_H表の索引を作成します。

4. EXCHANGE PARTITIONコマンドを発行します。

Alter table dwb_pnr_h exchange partition SYS_P1926 with    table tmp_pnr including indexes without validation;

5. 増分統計を使用して、新しく交換したパーティションのオプティマイザ統計を収集します。

この例のEXCHANGE PARTITIONコマンドは、名前が付いたパーティションおよびtmp_pnr表の定義をスワップするので、パーティション表の正しい場所にデータがすぐに配置されます。また、INCLUDING INDEXESおよびWITHOUT VALIDATION句を使用すると、索引の定義をスワップし、データが実際にパーティションに属するかどうかを確認しないため、交換が非常に迅速になります。

注意:
この例の想定では、データの整合性がデータ抽出時間に確認されました。データの整合性がわからない場合、データベースでデータの妥当性を確認するため、WITHOUT VALIDATION句を省略します。

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

Intra-ETLは、Oracle Airlines Data Modelのコンポーネントとして提供されています。このIntra-ETLは、PKG_INTRA_ETL_PROCESSという名前のPL/SQLパッケージとして提供され、これは、アクセス・レイヤーに移入するプロシージャを持つ完全なIntra-ETLプロセスです。

PKG_INTRA_ETL_PROCESSパッケージは、個別のサブプロセス・プロシージャ、および各個別のプログラムの依存性を順守する機能で構成されます。主要なプロシージャは次の順序で実行されます。

1. Populate_Dimension: 参照表(DWR_)の内容に基づいて、ディメンション表(DWM_)に移入します。

2. Populate_Derived: 実表(DWB_)の内容に基づいて、導出表(DWD_)に移入します。

3. Populate_Aggregate: ディメンション表(DWM_)および導出表(DWD_)のデータを使用して、集計表(DWA_)のすべてをリフレッシュします。

4. Populate_Aw: Oracle Airlines Data Modelの集計表(DWA_)のデータをOracle Airlines Data Model Analytical Workspaceにロードし、予測データを計算します。DWC_OLAP_ETL_PARM表からOLAP ETLパラメータを読み取ります。

5. Populate_MINING: データ・マイニング・モデルをトリガーします。

PKG_INTRA_ETL_PROCESSパッケージは、デフォルトのOracle Airlines Data Modelで動作するように設計されています。モデルをカスタマイズしている場合は、Intra-ETLもカスタマイズする必要があります。Oracle Airlines Data Modelに提供されているIntra-ETLをカスタマイズするには、次の手順に従います。

1. PKG_INTRA_ETL_PROCESSパッケージの内容をよく理解します。特に、『Oracle Airlines Data Modelリファレンス』に記載されているプロシージャ、データ・フローおよびマップについて、ならびにプロシージャでDWC_ETL_PARAMETERとDWC_OLAP_ETL_PARM制御表、およびDWC_INTRA_ETL_PROCESSとDWC_INTRA_ETL_ACTIVITY制御表がどのように使用されるかについて理解します。次のトピックを確認してください: 「アクセス・レイヤーの初期ロードの実行」、「Oracle Airlines Data Modelウェアハウスのアクセス・レイヤーのリフレッシュ」、および「Oracle Airlines Data Model Intra-ETLの実行中のエラー管理」。

2. Oracle Airlines Data Modelに行った変更、およびそれらのモデル変更をサポートするためにIntra-ETLに行う必要のある変更を特定します。

3. 変更する必要があるパッケージのコピーを作成します。コピーには別の名前を指定してください。

4. ステップ2で特定した変更を、ステップ3で作成したパッケージに行います。

オプションとして、独自のPL/SQLコードを記述するか、Oracle Warehouse BuilderなどのETLツールを使用して、新しいIntra-ETLを最初から作成できます。

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

Oracle Airlines Data Modelの初期ロードの実行は、複数ステップのプロセスです。

1. 「基盤レイヤーの初期ロードの実行」の説明に従って、Oracle Airlines Data Modelウェアハウスの基盤レイヤー(つまり、参照表、検索表および実表)をロードします。

2. 「アクセス・レイヤーの初期ロードの実行」の説明に従って、Oracle Airlines Data Modelウェアハウスのアクセス・レイヤー(つまり、導出表および集計表、導出表と集計表のディメンションを提供する表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)をロードします。

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

作成したSource-ETLを使用して、基盤レイヤーの初期ロードを実行します。このETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。

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

Oracle Airlines Data Modelウェアハウスのアクセス・レイヤー(導出表、集計表、マテリアライズド・ビュー、OLAPキューブおよびデータ・マイニング・モデル)の初期ロードを実行するには、次の手順に従います。

1. oadm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新して、この情報(ETL期間の開始日と終了日)をアクセス・レイヤーへのデータのロード時にETLで使用できるようにします。
Oracle Airlines Data Modelウェアハウスの初期ロードでは、次の表に示す値を指定します。

列

値

PROCESS_NAME

'OADM-INTRA-ETL'

FROM_DATE_ETL

ETL期間の開始日。

TO_DATE_ETL

ETL期間の終了日。

参照:
DWC_ETL_PARAMETER制御表の詳細は、『Oracle Airlines Data Modelリファレンス』を参照してください。

2. oadm_sysスキーマ内のDWC_OLAP_ETL_PARM制御表のOracle Airlines Data Model OLAP ETLパラメータを更新して、構築メソッドおよびその他の構築特性を指定し、この情報をOLAPキューブ・データのロード時にETLで使用できるようにします。
分析ワークスペースの初期ロードの場合は、表4-1のガイドラインに従って値を指定します。

表4-1 初期ロード用のDWC_OLAP_ETL_PARM表のOracle Airlines Data Model OLAP ETLパラメータの値

列名

値

PROCESS_NAME

'OADM-INTRA-ETL'

BUILD_METHOD

C。この値は、ロード前にすべてのディメンション値をクリアする完全リフレッシュを指定します。

CUBENAME

構築するキューブを指定する次の値のいずれか。

- ALLは、Oracle Airlines 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 Airlines Data ModelのIntra-ETLの実行」で説明している方法の1つを使用して、Intra-ETLを実行します。

関連項目:
「Oracle Airlines Data Modelウェアハウスのデータのリフレッシュ」

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

Oracleクライアント・ツール(SQL Plusなど)から次の文を発行して、PKG_INTRA_ETL_PROCESSプロセス・フローを実行します。

EXEC PKG_INTRA_ETL_PROCESS.RUN( )

PKG_INTRA_ETL_PROCESSによって実行されるPL/SQLコード:

- 適切な順序でマッピングを実行する前に、oadm_sysスキーマ内のDWC_ETL_PARAMETERおよびDWC_OLAP_ETL_PARM制御表から値を読み取ります。

- 各表のロードの結果は、DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITY制御表で追跡されます。

Oracleクライアント内からPKG_INTRA_ETL_PROCESSを実行すると、プロセスの実行を監視する機能が提供されます。ただし、PKG_INTRA_ETL_PROCESS PL/SQLパッケージ内のRUNプロシージャを単純に実行できます。

どちらの場合でも、Intra-ETLを明示的に実行したり、他のプログラムまたはプロセス(たとえば、正常な実行の後のSource-ETLプロセスなど)または事前定義済のスケジュール(たとえば、Oracle Job Scheduling機能の使用など)で実行を起動したりできます。

参照:
「Intra-ETLプロセスの実行の監視」、「Intra ETLプロセスのリカバリ」および「Intra-ETLのパフォーマンスのトラブルシューティング」。

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

「アクセス・レイヤーの初期ロードの実行」では、Oracle Airlines Data Modelデータ・ウェアハウスの初期ロードの実行方法について説明しています。この初期ロードの後に、ビジネス分析を容易にするという目的を満たせるように、Oracle Airlines Data Modelデータ・ウェアハウスに新規データを定期的にロードする必要があります。

Oracle Airlines Data Modelウェアハウスに新規データをロードするには、1つ以上の業務系システムからデータを抽出し、そのデータをウェアハウスにコピーする必要があります。データ・ウェアハウス環境では、多数のシステムにわたる大量のデータを統合、再配置および連結し、結果として、統一された新たな情報ベースをビジネス・インテリジェンスに提供することが課題になります。

継続的なロードおよび変換は、特定の順序でスケジュールして処理する必要があり、ビジネス・ニーズによって決定されます。操作または操作の一部が成功したか失敗したかに応じて、結果を追跡する必要があります。また、場合によっては後続の代替プロセスを開始できます。

Oracle Airlines Data Modelウェアハウスの完全増分ロードを実行するか、データを順次にリフレッシュできます。

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

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

どちらの場合でも、「Oracle Airlines Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。

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

Oracle Warehouse Builderまたは別のETLツールを使用して書き込まれたSource-ETLスクリプトを使用して、基盤レイヤーをリフレッシュします。Source-ETLの作成の詳細は、「Oracle Airlines Data Modelウェアハウスの基盤レイヤーのETL」を参照してください。

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

Oracle Airlines Data Modelのアクセス・レイヤーのリフレッシュは、複数ステップのプロセスです。「デフォルトのOracle Airlines Data ModelのIntra-ETLの実行」の説明に従ってPKG_INTRA_ETL_PROCESSパッケージを実行することでアクセス・レイヤーの完全増分ロードを一度に実行するか、または、データを順次にリフレッシュできます。

1. Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表のリフレッシュ

2. Oracle Airlines Data ModelのOLAPキューブのリフレッシュ

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

どちらの場合でも、「Oracle Airlines Data ModelのIntra-ETL実行中のエラーの管理」の説明に従って、Intra-ETLの実行中のエラーを管理できます。

Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表のリフレッシュ

Oracle Airlines Data Modelの基盤レイヤーをリフレッシュした後。次の手順を実行して、Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表およびビューのみをリフレッシュできます。

1. oadm_sysスキーマ内のDWC_ETL_PARAMETER制御表のパラメータを更新します。Oracle Airlines Data Modelウェアハウスの増分ロードの場合は、次の表で示す値を指定します(ETL期間の開始日と終了日)。

列

値

PROCESS_NAME

'OADM-INTRA-ETL'

FROM_DATE_ETL

ETL期間の開始日。

TO_DATE_ETL

ETL期間の終了日。

参照:
DWC_ETL_PARAMETER制御表の詳細は、『Oracle Airlines Data Modelリファレンス』を参照してください。

2. 「デフォルトのOracle Airlines Data ModelのIntra-ETLの実行」で説明しているPKG_INTRA_ETL_PROCESS PL/SQLパッケージ内の次のプロシージャを実行して、表をリフレッシュします。次の順序でプロシージャを実行します。

1. Populate_Dimension

2. Populate_Derived

3. Populate_Aggregate

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

スケジュールに基づいて、OLAPキューブの初期ロード以降にOracle Airlines Data Modelデータ・ウェアハウスに追加されたリレーショナル・データでOLAPキューブ・データを更新する必要があります。

Oracle Airlines Data Modelウェアハウス内のOLAPキューブ・データのみをリフレッシュするには、次の手順を実行します。

1. 基礎となる集計表がリフレッシュされることを確認します。詳細は、「Oracle Airlines Data Modelのアクセス・レイヤーのリレーショナル表のリフレッシュ」を参照してください。

2. PKG_INTRA_ETL_PROCESS.Populate_Awプロシージャを実行して、キューブ・データをロードします。

3. 必要に応じて、次の手順を実行して、Populate_Awの実行中に発生するエラーからリカバリします。

1. DWC_OLAP_ETL_PARM表のBUILD_METHOD列の値を"C"に変更します。

2. PKG_INTRA_ETL_PROCESS.Populate_Awを再実行します。

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

PKG_INTRA_ETL_PROCESS.Populate_Miningプロシージャは、ウェアハウスの初期ロードの一部としてデータ・マイニング・モデルのリフレッシュメントをトリガーします。ウェアハウスの初期ロード後に、データ・マイニング・モデルを毎月リフレッシュすることをお薦めします。

OLAPキューブをリフレッシュした後、データ・マイニング・モデルもリフレッシュできます。この場合、データ・マイニング・モデルをリフレッシュする方法は、すべてのデータ・マイニング・モデルまたは1つのデータ・マイニング・モデルのみをリフレッシュするかどうかによって異なります。

- すべてのデータ・マイニング・モデルを手動でリフレッシュするには、次のプロシージャをコールします。
oadm_sys.pkg_oadm_mining.refresh_model(p_month_code,p_process_no)

このプロシージャは、各データ・マイニング・モデルで次のタスクを実行します。

1. oadm_sysスキーマの最新データに基づいてデータ・マイニング・モデルのソース・マテリアライズド・ビューをリフレッシュします。

2. 新しいトレーニング・データで各データ・マイニング・モデルをトレーニングします。

3. 各データ・マイニング・モデルを新規適用データ・セットに適用します。

- 1つのデータ・マイニング・モデルのみ手動で再作成するには、対応するoadm_sys.pkg_oadm_mining.create_プロシージャをコールします。
たとえば、顧客生涯価値回帰データ・マイニング・モデルを再作成するには、次のプロシージャをコールします。

oadm_sys.pkg_oadm_mining.create_cust_ltv_svm_rgrsn(p_month_cd);

「チュートリアル: 顧客生涯価値予測データ・マイニング・モデルのカスタマイズ」に、単一のデータ・マイニング・モデルをリフレッシュする詳細な手順を示します。

関連項目:
「データ・マイニング・モデルの作成のトラブルシューティング」

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

このトピックでは、Intra-ETL実行中のエラーを識別および管理する方法について説明します。この付録には、次の項があります。

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

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

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

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

Intra-ETLプロセスの実行は、2つのoadm_sysスキーマ制御表DWC_INTRA_ETL_PROCESSおよびDWC_INTRA_ETL_ACTIVITYによって監視されます。これらの表については、『Oracle Airlines Data Modelリファレンス』に記載されています。

個々のPKG_INTRA_ETL_PROCESSパッケージの通常の実行では、(エラー・リカバリ実行ではなく)次の手順を実行します。

1. 単調に増加するシステム生成の一意のプロセス・キー、プロセス開始時刻としてのSYSDATE、プロセス・ステータスとしてのRUNNING、およびフィールドFROM_DATE_ETLとTO_DATE_ETLの入力日範囲で、DWC_INTRA_ETL_PROCESS表にレコードを挿入します。

2. 適切な依存性の順序で各PKG_INTRA_ETL_PROCESSプロシージャが起動されます。各プログラムの起動前に、システム生成の一意のアクティビティ・キー、Intra-ETLプロセスに対応するプロセス・キー値、Activity Nameに個々のプログラム名、適切なアクティビティの説明、アクティビティ開始時間にSYSDATE、アクティビティ・ステータスにRUNNINGが指定されたレコードがIntra-ETLアクティビティ・ディテール表DWC_INTRA_ETL_ACTIVITYに挿入されます。

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プロセスのリカバリ

PKG_INTRA_ETL_PROCESSパッケージの実行をリカバリするには、次の手順を実行します。

1. DWC_INTRA_ETL_ACTIVITY表の個々のプログラムに対して追跡されているエラー詳細を参照することでエラーを識別します。

2. エラーの原因を修正します。

3. PKG_INTRA_ETL_PROCESSパッケージを再実行します。

PKG_INTRA_ETL_PROCESSパッケージのプロシージャは、DWC_INTRA_ETL_ACTIVITY表を参照することで通常の実行かリカバリ実行かを識別します。リカバリの実行中、PKG_INTRA_ETL_PROCESSは、リカバリに必要なプロシージャのみを実行します。たとえば、前回の実行の一部として導出移入エラーが発生した場合、このリカバリ実行は、前回の実行でエラーを生成した個々の導出移入プログラムを実行します。正常完了後に、集計移入プログラムとマテリアライズド・ビューのリフレッシュが適切な順序で実行されます。

このように、Intra-ETLエラー・リカバリはほとんど透過的であり、データ・ウェアハウス管理者またはETL管理者は関与しません。管理者は、エラーの原因を修正して、PKG_INTRA_ETL_PROCESSパッケージを再起動するだけです。PKG_INTRA_ETL_PROCESSが、エラーを生成したプログラムを識別して実行します。

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 Airlines Data Modelでのパラレル実行」

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

データ・マイニング・モデルが作成された後で、oadm_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 Airlines Data Modelを操作する場合にERROR_DTLおよびACTIVITY_NAMEで戻される一般的なエラー・メッセージのトラブルシューティング方法を示します。

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

- 例4-3「ORA-40112のトラブルシューティング: 有効なデータ行数が不足しています」

- 例4-4「ORA-40113のトラブルシューティング: 個別ターゲット値の数が不足しています」

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

戻されるエラーがメッセージはありません... [言語=ZHS]とします。

'ZHS'は言語のコードです。関連する言語名は、データベース環境に応じて異なる名前で表示されることがあります。このエラーは、oadm_sys.DWC_MESSAGE.LANGUAGEに現在の言語用のメッセージが含まれていない場合に発生します。

DWC_MESSAGE表の値をチェックし、必要に応じて、Oracleセッション変数USERENV('lang')で指定されている言語コードに更新します。

例4-3 ORA-40112のトラブルシューティング: 有効なデータ行数が不足しています

戻されるエラーが"create_cust_ltv_svm_rgrsn"モデルに対するORA-40112: 有効なデータ行数が不足していますとします。

このモデルでは、ターゲット列はoadm_sys.dmv_cust_ltv_src.tot_cpn_amtです。

このエラーをトラブルシューティングする手順は、次のとおりです。

1. 次のSQL文を実行します。

SELECT count(tot_cpn_amt) FROM dmv_cust_ltv_src;
SELECT count(frqtflr_card_key) FROM dmv_cust_ltv_src;

2. 前述の2つの問合せで戻される値が、0(ゼロ)以上であることを確認します。最初のSELECT文で戻される値が、2番目のSELECT文で返される値よりも小さい場合、dmv_cust_ltv_srcのソース表およびマテリアライズド・ビューを確認します。

例4-4 ORA-40113のトラブルシューティング: 個別ターゲット値の数が不足しています

戻されるエラーが"create_ffp_pred_svm"モデルに対するORA-40113: 個別ターゲット値の数が不足していますとします。2クラス分類モデルの場合、ターゲット列には2つの個別の値が必要です。このエラーは、トレーニング・モデルのターゲット列に2つの値が期待されている場合に、1つの値のみ含まれているか、値が含まれていない場合に発生します。

たとえば、利用頻度の低い乗客の中での利用頻度の高い乗客予測svmモデルの場合、ターゲット列はoadm_sys.dmv_ffp_pred_src.ff_indとなります。

このエラーをトラブルシューティングする手順は、次のとおりです。

1. SQL問合せを実行して、この列に十分な値があるかどうかを確認します。利用頻度の高い乗客予測svmモデルを例として使用し、次の文を発行します。

SELECT ff_ind, count(*) FROM dmv_ffp_pred_src GROUP BY ff_ind;

問合せの結果を次に示します。

FF_IND       COUNT(*)
------       --------
1           1296
0            990

2. 次の問合せを発行して、次の表に利用頻度の高い乗客および利用頻度の低い乗客の両方が存在することを確認します。

SELECT NVL2(frqtflr_nbr,'FFP','Non_FFP') AS ffp_ind, count(*)
FROM oadm_sys.dwd_bkg_fact GROUP BY NVL2(frqtflr_nbr,'FFP','Non_FFP');

この問合せの結果を次に示します。

FFP_IND       COUNT(*)
-------       --------
Non-FFP          77353
FFP              42647

3. 次の文を実行して、マイニング・ソース・マテリアライズド・ビューをリフレッシュします。

exec pkg_oadm_mining.refresh_mining_source;

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

この章では、Oracle Airlines Data Modelウェアハウスのデータのレポート、問合せおよびダッシュボードの作成について説明します。この付録には、次の項があります。

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

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

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

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

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

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

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

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

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

Oracle Airlines Data Modelウェアハウスのデータからレポートを作成する2つの主なアプローチがあります。

- リレーショナル・レポート
リレーショナル・レポートでは、スターのディメンションとして機能するディメンションまたは検索表とともにスターの中心にファクト表を使用して、分析レイヤー・エンティティのレポートを作成します。通常、ファクトは、DWM_ディメンションを含む導出表(DWD_)および集計表(DWA_)です。ただし、詳細なレポートを生成するため、参照表(DWR_)または検索表(DWL_)とともに実表(DWB_)を使用する必要がある場合があります。

- 通常、ディメンション(DWM_)表は、ビジネス階層を含むディメンションを表し、各レベルの階層の表を含むスノーフレーク・エンティティの形式で存在します。これにより、異なる精度で構成される複数のサブジェクト領域およびファクト・エンティティの参照表の適切なセットを関連付けることができます。たとえば、時間ディメンション表(DWM_CLNDR)を使用して、DWD_PNRなどの、DAYレベルの乗客名レコード(PNR)データに対して問合せできます。

- 参照表(DWR_)および検索表(DWL_)は、値のフラット・リストを含む単一のレベルで構成されるより単純なディメンションを表します。通常、ほとんどのレポート・ツールは、表面的な最上位レベルをディメンションに追加します。これらは、DWL_で始まる個々の表またはまたは様々なコード・タイプを個別のディメンションに分割するDWL_CODE_MASTERのビュー(DWL_という名前)の可能性があります。

- OLAPレポート
OLAPレポートでは、ディメンションおよびキューブ(ファクト)ビューに対してSQLを使用して、Oracle OLAPキューブにアクセスします。キューブおよびディメンションは、スター・スキーマ設計を使用して表されます。ディメンション・ビューは、キューブ(またはファクト)ビューの周囲に集団を形成します。ディメンションのビューおよびキューブ・ビューは、_VIEWで終わる名前を使用したリレーショナル・ビューです。

- OLAPディメンション・ビューは、レベル列(level_nameとして識別されます)に基づいて論理的にパーティション化されるすべてのレベルの階層を含む全体のディメンションに関連する情報を含みます。OLAPディメンションは、スノーフレーク・ディメンション表のフラット化されたビューと考えることができます。通常、Oracle Airlines Data Modelでは、ディメンション・ビューは、dimension_hierarchy_VIEWという名前になります。

- キューブ・ビューは、キューブ定義の一部である個々のディメンションのレベルの様々な組合せに関連するファクトを含みます。また、キューブ・ビューおよびディメンション・ビューの結合は、必要なディメンション・レベル・フィルタとともにディメンション・キーに基づいています。通常、Oracle Airlines Data Modelでは、キューブ・ビューは、cube_VIEWという名前になります。

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 Airlines Data Modelレポートの作成方法について説明します。Oracle Airlines Data Modelレポートの例は、次を参照してください。

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

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

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

- Oracle Airlines Data Modelで提供されているサンプル・レポート(『Oracle Airlines Data Modelリファレンス』で説明されています)。

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

サンプル・レポートとダッシュボードは、Oracle Airlines Data Modelで提供されます。これらのサンプル・レポートは、Oracle Airlines Data Modelに付属の分析機能(OLAPやデータ・マイニング機能など)を示しています。

参照:
サンプル・レポートのインストール、ならびにBusiness Intelligence Suite Enterprise EditionインスタンスでのOracle Airlines Data Model RPDおよびWebcatのデプロイの詳細は、『Oracle Airlines 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 Airlines Data Modelリファレンス』を参照してください。

注意:
例に使用される、Oracle Airlines Data Modelに付属のレポートおよびダッシュボードは、デモの目的にのみ利用できます。Oracleによるサポートはありません。

問合せとレポートの作成

oadm_sysスキーマは、Oracle Communications Data Modelのリレーショナル表およびビューを定義します。任意のSQLレポート・ツールを使用して、これらの表およびビューに対する問合せおよびレポートを行うことができます。

Oracle Airlines Data Modelでは、oadm_sysスキーマに定義されているOLAPキューブを使用したオンライン分析処理(OLAP)レポートもサポートされます。SQLツールを使用してキューブに対して定義されているビューを問い合せるか、OLAPツールを使用してOLAPコンポーネントを直接問い合せることで、OLAPキューブの問合せおよびOLAPキューブに関するレポートの作成を行うことができます。

関連項目:
「Oracle Airlines Data Modelのレポート・アプローチ」、「Oracle OLAPキューブ・ビュー」および『Oracle OLAPユーザーズ・ガイド』のディメンション・オブジェクトの問合せの説明。

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

たとえば、2010年2月のビジネス・クラスの合計予約数を知る必要がある場合を想定します。この質問に回答するには、次の表で説明する表を問い合せる必要があります。

エンティティ名

表名

説明

日次予約ファクト

DWA_DLY_BKG_FACT

予約関連のファクト・データを格納します。

予約クラス・ファクト

DWM_BKG_CLS_TYP

ビジネス、エコノミーなどの予約クラス・タイプ。

カレンダ

DWM_CLNDR

カレンダ情報を格納します。

問合せを行うには、次のSQL文を実行します。

select DWM_CLNDR.CLNDR_MONTH_CD,DWM_BKG_CLS_TYP.SVC_CLS_DESC,sum(DWA_DLY_BKG_FACT.BKD) as Booking_Count
from DWA_DLY_BKG_FACT,DWM_CLNDR,DWM_BKG_CLS_TYP
where DWM_CLNDR.CLNDR_KEY=DWA_DLY_BKG_FACT.BKG_DT_KEY
and DWM_BKG_CLS_TYP.BKG_CLS_KEY=DWA_DLY_BKG_FACT.BKG_CLS_KEY
and DWM_BKG_CLS_TYP.SVC_CLS_DESC='BUSINESS'
and DWM_CLNDR.CLNDR_MONTH_KEY=20100201
group by DWM_CLNDR.CLNDR_MONTH_CD, DWM_BKG_CLS_TYP.SVC_CLS_DESC

この問合せの結果を次に示します。

CLNDR_MONTH_CD            SVC_CLS_DESC            BOOKING_COUNT
------------------------- --------------------    ----------------------
20100201                  BUSINESS                61

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

アクセス・レイヤーの通常の問合せは、ファクト表と多数のディメンション表の結合で、一般的にスター・クエリーと呼ばれます。スター・クエリーで、各ディメンション表は、主キーと外部キーの結合を使用してファクト表に結合されます。通常、ディメンション表は相互に結合しません。

通常、このような問合せで、すべての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フェーズまたは後戻り結合フェーズの実行中です。

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

次のアクションを実行して、Oracle Business Intelligence Suite Enterprise Editionを使用して作成されたレポートの生成に関する問題を識別します。

1. (オンライン) Oracle BI Administratorツールで、「管理」、「セキュリティ」、「ユーザー」、「oadm」の順に選択します。
「ロギング・レベル」の値が7であることを確認します。

2. Oracle Airlines Data Modelリポジトリを開き、「管理」、「キャッシュ」の順に選択します。

3. キャッシュ・マネージャ・ウィンドウの右側のペインで、すべてのレコードを選択し、右クリックして「パージ」を選択します。

4. SQLログを使用して、追跡するレポートまたは問合せを実行します。

5. OracleBI\server\Logにある問合せログ・ファイル(NQQuery.log)を開きます。
最後の問合せSQLは、実行したレポートのログです。最後にアクセスしたレポートでエラーが戻される場合、このログの最後にエラーがあります。

次の例は、これらのエラー・メッセージの使用方法を示します。

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

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

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

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

ログ・ファイルに次のエラーが含まれているとします。

Query Status: Query Failed: [nQSError: 15018] Incorrectly defined logical table source (for fact table Booking Segment Departure Fact) does not contain mapping for [Booking Segment Departure Fact.Confirmed Count, Booking Segment Departure Fact.Belly Cargo Revenue].

このエラーは、Oracle Business Intelligence Suite Enterprise Editionリポジトリのビジネス・レイヤーに問題がある場合に発生します。

この場合、Booking Segment Departure Fact.Confirmed CountおよびBooking Segment Departure Fact.Belly Cargo Revenueのマッピングを確認する必要があります。

例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問合せの特性

- 例: 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属性の適用によって正しく追加されます。

例: 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 Airlines Data Modelダッシュボードの作成

このチュートリアルは、Oracle Airlines Data Modelに付属しているサンプルのOracle Business Intelligence Suite Enterprise Editionレポートに含まれるOracle Airlines Data Model Webcat内のダッシュボードに基づいて新しいダッシュボードを作成する方法について説明しています。

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

この例では、「代理店収益および予約分析」という名前のダッシュボードを作成し、代理店収益分析(USD)と代理店パフォーマンス分析PCT CANCELの両方を新規ダッシュボードに組み込むとします。

ダッシュボードを作成するには、次の手順を実行します。

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

2. Oracle Business Intelligence Suite Enterprise Editionダッシュボードを作成するには、「新規」、「ダッシュボード」の順に選択します。

3. 名前と説明を入力します。「ダッシュボード」フォルダにダッシュボードを保存します。「OK」をクリックします。

4. 「カタログ」ビューで、収益分析フォルダを展開します。代理店収益分析(USD)レポートが表示されるので、これをカタログ・ビューから右パネルにドラッグします。

5. 「カタログ」ビューで、収益分析フォルダを展開します。代理店パフォーマンス分析PCT CANCELレポートが表示されます。このレポートを「カタログ」ビューから右パネルにドラッグします。

6. このセクションのレイアウトを変更して、水平または垂直の2つのレポートを編成できます。

ページ名が"Page1"のままなので、変更する必要があります。

7. ページ名を変更するには、次の手順を実行します。

1. ダッシュボードを選択します。

2. 「ダッシュボードのプロパティ」ウィンドウで、「名前の変更」をクリックします。

3. 名前を「代理店収益および予約分析」に変更し、「OK」をクリックします。

8. ダッシュボードの上部の「保存」をクリックします。新しいダッシュボードが表示されます。

Oracle By Example:
レポートの作成の詳細は、AnalysesおよびDashboards 11gの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

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

このチュートリアルは、Oracle Airlines Data Modelに付属しているサンプルのOracle Business Intelligence Suite Enterprise Editionレポートに含まれるOracle Airlines Data Model Webcat内のレポートに基づいて新しいレポートを作成する方法について説明しています。

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

この例では、「Agent Booking and Flown Revenue」という名前のレポートを作成し、予約数と飛行収益の両方を1つのレポートに組み込むとします。

この新しいレポートを作成するには、次の手順を実行します。

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

2. Oracle Business Intelligence Suite Enterprise Editionレポートを作成するには、「新規」、「分析」の順に選択します。

3. 「サブジェクト領域」、「OADM_OLAP」の順に選択して、リレーショナル・レポートを作成します。

4. ディメンションおよびファクト列を「列の選択」パネルにドラッグして配置します。

5. 「結果」タブを選択して、レポートを表示します。

6. 「新規」を選択して、チャートをレポートに追加します。

7. 「保存」を選択して、このレポートをネットワーク・ヘルス分析フォルダに保存します。

Oracle By Example:
レポートの作成の詳細は、AnalysesおよびDashboards 11gの作成に関するOBEチュートリアルを参照してください。
チュートリアルにアクセスするには、「Oracle Technology Network」の指示に従ってブラウザでOracle Learning Libraryを開き、名前でチュートリアルを検索します。

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

この付録では、Oracle Airlines Data Modelウェアハウスのサイズ設定および構成について説明します。この付録には、次の項があります。

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

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

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

企業は、より迅速により多くの情報を求め、エンタープライズ・データ・ウェアハウス(EDW)から常に拡大する一連のユーザーおよびアプリケーションに至るまで分析を行っています。この需要の増加に対応していくため、EDWはほぼリアルタイムで高可用性を実現する必要があります。データ・ウェアハウスの設計または実装に関係なく、優れたパフォーマンスの最初の秘訣は、使用するハードウェア構成にあります。これは、市場のデータ・ウェアハウス・アプライアンスの数の最近の増加から何よりも明白です。

ただし、このようなシステムのサイズ設定はどうすればよいでしょうか。システムに必要なスループット量および構成の個々のCPUまたはコアで実行できるスループット量を最初に理解する必要があるため、最優先の課題は、データ・ウェアハウスのデータベース領域要件を計算することです。

データ・ウェアハウス環境には、2つのデータ量の見積もりリソースがあります。

- ソース・システムからの見積もられたRAWデータの抽出。この見積もりは、ETLシステム構成およびデータ・ウェアハウス・システムのステージ・レイヤー・データベース領域に影響します。この値は一意のOLTPシステムによって決定されるため、ユーザーがこの情報を計算する必要があります。

- デフォルトのOracle Airlines Data Modelスキーマで定義されるオブジェクトをサポートするために格納されるデータに必要な領域。この付録では、この計算を行うために使用できる情報について説明します。

Oracle Airlines Data Modelウェアハウスのデータ量の計算を行う場合の計算要素

データ量の計算を行う場合、次の計算要素を検討します。

- 異なるタイプのデータ単位量を計算します。

- 参照表および検索表のデータ。このデータが永久に格納されると想定します。

- 実表のデータ(トランザクション・データ)。このデータがライフ・サイクル内で格納されると想定します。

- スター・スキーマ(導出およびサマリー)。このデータがライフ・サイクル内で格納されると想定します。

- 各タイプのデータの保持を計算します。

- 各タイプの表を保持する月数または年数を定義します。

- データの増加を計算します。

- 年間成長率がトランザクションおよび参照データとスター・スキーマのデータに適用されると想定します。

- 年間変更率が参照データにのみ適用されると想定します。

- 提案された場合、ステージング領域のデータ要件を計算します。

ヒント:
日単位のETLボリュームを問題解決およびソース・システムからの新しい抽出による変換の再実行のために用意された日数で乗算します。

- 索引、一時表およびトランザクション・ログのデータ量を計算します。

- キューブやデータ・マイニングなどのビジネス・インテリジェンス・ツールの領域要件を計算します。

- REDOログおよびOracle ASM領域要件を検討します。

- RAIDアーキテクチャ[RAID 1、0+1、5]を検討します。

- バックアップ戦略を検討します。

- 該当する場合、圧縮要素を検討します。

- OSおよびファイル・システムのディスク領域要件を検討します。

Oracle Airlines Data Modelウェアハウスの最小ディスク領域要件を決定する式

Oracle Airlines Data Modelウェアハウスの最小ディスク領域要件を決定するため、「Oracle Airlines Data Modelウェアハウスのデータ量の計算を行う場合の計算要素」に概説された要素に基づいて、次の式を使用します。

ディスク領域の最小要件 = RAWデータ・サイズ * データベース領域要素 * (1+GrthperY)nY*OSおよびファイル・システム要素 * 圧縮要素 * ストレージ冗長要素

説明:

- RAWデータ・サイズ = (年ごとの参照および検索データ + 年ごとの実/トランザクション・データ + 年ごとの導出およびサマリー・データ +ステージング・データ +他のデータ(OLAP/データ・マイニング))

- データベース領域要素 = 索引 + 一時表 + ログ]

- GrthperY = 年ごとの成長率

- OSおよびファイル・システム要素は、OSおよびデータベースのインストール、構成および保守領域です。

- 冗長要素= ASMディスク領域およびRAID要素。[RAID 1=2、RAID 5=1.25または1.33]

- 圧縮要素は、圧縮機能の適用方法に依存します。HCCを使用している場合、圧縮を使用するとディスク領域が大幅に節約されます。

Oracle Airlines 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 Airlines Data Modelのバランスのとれたステムの構成について説明します。

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

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

- Oracle Airlines Data Modelの拡張計画

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

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

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

データのサイズが大規模であるため、データ・ウェアハウスに必要とされるハードウェア構成とデータ・スループットは一意です。データ・ウェアハウスのハードウェア構成のサイズ設定を開始する前に、最も高いスループット要件を見積もり、現在または提案済のハードウェア構成で必要なパフォーマンスを提供できるかどうかを決定します。スループットを見積もる場合、次の基準を使用します。

- ピーク時に問合せによりアクセスされるデータ量および許容できるレスポンス時間。

- 一定期間内にロードされるデータ量。

容量ではなくバンド幅のOracle Airlines 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 Airlines Data Modelの拡張計画

データ・ウェアハウスの設計者は、データ・ウェアハウスの将来的な拡張を考慮して計画を立てます。システムの拡張に対応するためのアプローチは複数ありますが、特に考慮する必要があるのは、I/O帯域幅を損うことなくI/Oシステムを拡張できるようにすることです。たとえば、20台のディスクで構成された既存のシステムに4台のディスクを追加し、4台の新しいディスクのみにわたってストライプ化された表領域を追加しても、データベースを拡張できません。より適切な解決策は、24台のディスクすべてにわたってストライプ化された表領域を新たに追加し、20台のディスクにストライプ化された既存の表領域を、24台のディスクすべてにストライプ化されるように徐々に変換していくことです。

Oracle Airlines Data Modelウェアハウスを作成する前のI/Oシステムのテスト

新しいシステムにデータ・ウェアハウスを構築する際は、すべてのデータベース・データ・ファイルを作成する前にI/O帯域幅をテストして、必要なI/Oレベルを達成できるかどうかを調べます。ほとんどのオペレーティング・システムでは、サイズの大きいテスト・ファイルの読取り/書込みパフォーマンスを計測する単純なスクリプトで、テストを実行できます。

Oracle Airlines 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を超えるサイズを簡単に設定できます。

索引

A  C  D  E  F  H  I  J  K  L  M  N  O  P  Q  R  S  T

A

アクセス・レイヤー, 2.1

カスタマイズ, 3, 3.1

Oracle Airlines Data Model, 2.1, 3

集計表

Oracle Airlines Data Model内, 3.4

As Isレポート, 5.6.1 As Wasレポート, 5.6.1

C

圧縮

Oracle Airlines Data Model内, 2.4.2, 2.4.2.1, 2.4.2.1.1

マテリアライズド・ビュー, 3.6.4

Oracle Airlines Data Modelウェアハウスの構成, A.2 表記規則

物理モデルをカスタマイズする場合, 2.2.2

キューブ

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

ディメンションの変更, 3.5.6

メジャーの変更, 3.5.6

カスタマイズ, 3.5.4

データのメンテナンス方法, 3.5.9

予測, 3.5.7

Oracle Airlines Data Model内, 3.5.4, 3.5.5

パーティション化, 3.5.8

カスタマイズ

アクセス・レイヤー, 3

キューブ, 3.5.4

Oracle Airlines Data Model, 1.2

物理データ・モデル, 2

D

ダッシュボード, Oracle Airlines Data Model, 5.2

データ管理委員会, 責任, 1.3.2

データ・マイニング・モデル

カスタマイズ, 3.3.2

導出表

Oracle Airlines Data Model内, 3.3

次元コンポーネント, Oracle Airlines Data Model, 3.5

E

エラー処理

Intra-ETLの実行中, 4.6

Oracle Airlines Data ModelのETL, 4.1

F

Oracle Airlines Data Modelのフィットギャップ分析, 1.5

Oracle Airlines Data Modelの予測キューブ, 3.5.7

基盤レイヤー

定義済, 2.1

Oracle Airlines Data Model, 2.1

H

HCC, 2.4.2.1.3

Hybrid Columnar圧縮

およびOracle Airlines Data Model, 2.4.2.1.3

I

Oracle Airlines Data Modelの実装者

前もって必要な知識, 13.1

実装

Oracle Airlines Data Model, 1.2

インデックス

Oracle Airlines Data Model内, 2.4.6

マテリアライズド・ビュー, 3.6.2

パーティション化, 2.4.6

整合性制約

Oracle Airlines Data Model内, 2.4.5

Intra-ETL

カスタマイズ, 4.3

エラーの管理, 4.6

実行の監視, 4.6.1

Oracle Airlines Data Model, 4.1

リカバリ 4.6.2

トラブルシューティング, 4.6.3

J

結合パフォーマンス, 改善, 2.4.7.3

K

キー, サロゲート

Oracle Airlines Data Model内, 2.4.4

L

Oracle Airlines Data Modelデータのロード, 4.4, 4.4.2

M

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

圧縮, 3.6.4

Oracle Airlines Data Model内, 3.6

索引付け, 3.6.2

パーティション・チェンジ・トラッキング, 3.6.3

パーティション化, 3.6.3

リフレッシュ・オプション

リフレッシュ, 3.6.1

メタデータ管理

リポジトリ, 1.4.2, 1.4.3

Oracle Airlines Data Modelによる, 1.4

メタデータ・リポジトリ, 1.4.2

参照, 1.4.3

Oracle Airlines Data Modelによる, 1.4.3

N

ネーミング規則

Oracle Airlines Data Modelの物理モデル, 2.2.2.1

O

Oracle Airlines Data Model

アクセス・レイヤー, 2.1, 3

コンポーネント, 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.5

ETL, 4.1

フィットギャップ分析, 1.5

基盤レイヤー, 2.1

実装, 1.2

Intra-ETL, 4.1

ロード, 4.4, 4.4.2

メタデータ管理, 1.4

メタデータ・リポジトリ, 1.4.2, 1.4.3

使用されるOracle製品, 1.1.2

物理レイヤー, 2.1

実装前タスク, 1.3

問合せ, 5.3

データのリフレッシュ, 4.5

レポート, 5.1, 5.3

サンプル・レポート, 5.2

Source-ETL, 4.1, 4.2, 4.2.2, 4.2.3, 4.2.4, 4.2.5

ステージング・レイヤー, 2.1

表領域, 設計の推奨事項, 2.4.1

Oracle Airlines Data Model実装者

前提知識, 1.3.1

Oracle Airlines Data Modelウェアハウス

構成, A.2

サイズ設定, A.1

Oracleデータ・マイニング・モデル

Oracle Airlines Data Model, 3.3.2.1

P

パラレル実行

セッションに対する有効化, 2.4.8.1

DML操作に対する有効化, 2.4.8.2

Oracle Airlines Data Model内, 2.4.8

パーティション・チェンジ・トラッキング, 3.6.3 パーティション交換ロード, 4.2.7.5 Oracle Airlines Data Modelのパーティション索引, 2.4.6 パーティション化

キューブ, 3.5.8

簡易データ・アクセス, 2.4.7.2

結合パフォーマンス, 2.4.7.3

管理性, 2.4.7.1

Source-ETL, 4.2.7.5

索引, 2.4.6

マテリアライズド・ビュー, 3.6.3

表, 2.4.7

パーティション, 変更, 2.4.1 Oracle Airlines Data Modelの物理モデル

特性, 2.1, 2.2, 2.2.1

カスタマイズ, 2.2.2

一般的な推奨事項, 2.4

Q

Oracle Airlines Data Modelの問合せ, 5.3

R

リフレッシュ

Oracle Airlines Dataウェアハウス, 4.5

レポート

Oracle Airlines Data Model, 5.1, 5.3

レポート

アプローチ, 5.1

As Is, 5.6.1

As Was, 5.6.1

パフォーマンスのトラブルシューティング, 5.5

レポート, Oracle Airlines Data Model

新規作成, 5.8

S

サンプル・レポート

カスタマイズ, 5.2

サイズ設定

Oracle Airlines Data Modelウェアハウス, A.1

Source-ETL

例外処理, 4.2.6

ジョブ制御, 4.2.5

ロードの考慮事項, 4.2.7

Oracle Airlines Data Model, 4.1, 4.2, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.7

パラレル・ダイレクト・パス・ロード, 4.2.7.4

パーティション化, 4.2.7.5

ワークフロー, 4.2.5

ステージング・レイヤー, 2.1

Oracle Airlines Data Model, 2.1

スター・クエリー, 最適化, 5.4 サブタイプ

表の定義, 2.4.3

物理実装, 2.4.3

スーパータイプ

表の定義, 2.4.3

物理実装, 2.4.3

サロゲート・キー

Oracle Airlines Data Model内, 2.4.4

T

表

集計, 3.4

圧縮, 2.4.2, 2.4.2.1, 2.4.2.1.1

導出, 3.3

パーティション化, 2.4.7

Oracle Airlines Data Modelの表領域, 2.4.1

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