Database 2日でデータ・ウェアハウス・ガイド

11g リリース2(11.2)

B56298-04(原本部品番号:E25555-03)

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

第I部 データ・ウェアハウスの構築

1 データ・ウェアハウスの概要

- このガイドについて

- このガイドを使用する前に

- このガイドの対象外

- データ・ウェアハウスについて

- データ・ウェアハウスの主な特性

- Oracleデータ・ウェアハウスの一般的なタスク

- このガイドで説明するタスク

- データ・ウェアハウス管理用ツール

2 データ・ウェアハウス・システムの設定

- データ・ウェアハウス・システムを設定する一般的な手順

- 環境の準備

- 適切なハードウェア設定

- 必要なCPU数およびクロック・スピードについて

- 必要なメモリーについて

- 必要なディスク数について

- 十分なI/O帯域幅を判断する方法について

- データ・ウェアハウスのハードウェア構成の検証

- ddユーティリティについて

- 例: ddユーティリティの使用

- Orionユーティリティについて

- データ・ウェアハウスのデータベースの設定

- メモリー管理パラメータの設定方法

- 例: 初期化パラメータの設定

- 重要な他の初期化パラメータの設定

- Oracle Warehouse Builderへのアクセス

- Oracle Warehouse Builderデモンストレーションのインストール

3 データ・ソースの識別およびメタデータのインポート

- データ・ソースの概要

- ソースからメタデータをインポートする一般的な手順

- Warehouse Builderのワークスペース、プロジェクトおよびその他のデバイスについて

- 例: フラット・ファイルからのメタデータのインポート

- フラット・ファイルの場所の指定

- プロジェクトでのモジュールの作成

- 「インポート・メタデータ・ウィザード」の起動

- 「フラット・ファイル・サンプル・ウィザード」の使用

- フラット・ファイル・データのインポート

4 Oracle Warehouse Builderでのウェアハウスの定義

- リレーショナル・ターゲット・ウェアハウスを定義する一般的な手順

- ウェアハウス・ターゲット・スキーマの指定

- Warehouse Builderのフラット・ファイルのソースについて

- 演習: ターゲット・モジュールへの外部表の追加

- ディメンションについて

- 演習: ディメンションの理解

- レベルについて

- レベル属性の定義

- 階層の定義

- ディメンション・ロール

- レベルの関係

- ディメンションの例

- 制御行

- ディメンションの実装

- スター・スキーマ

- バインド

- キューブについて

- キューブの定義

- キューブ・メジャー

- キューブのディメンション

- キューブの例

- キューブの実装

- キューブのリレーショナル実装

- バインド

第II部 データ・ウェアハウスへのデータのロード

5 ETLロジックの定義

- マッピングおよび演算子について

- マッピングを定義する手順の要約

- マッピングの作成

- 演算子のタイプ

- 演算子の追加

- ワークスペース・オブジェクトにバインドする演算子の追加

- バインドされていない演算子を属性なしで作成

- 既存のワークスペース・オブジェクトから選択してバインド

- 演算子の編集

- 演算子、グループおよび属性の接続

- 演算子の接続

- グループの接続

- 例: マッピング・エディタによるステージング領域表の作成

- 属性の接続

- 演算子、グループおよび属性プロパティの設定

- 演算子とワークスペース・オブジェクトの同期化

- 演算子の同期化

- ワークスペース・オブジェクトから演算子への同期化

- ワークスペース・オブジェクトに基づく演算子の同期化

- 演算子からワークスペース・オブジェクトへの同期化

6 ターゲット・スキーマへの配布およびETLロジックの実行

- 配布について

- コントロール・センターの概要

- 配布の物理詳細の構成

- 配布アクション

- 配布プロセス

- オブジェクトの配布

- ETLジョブの開始

- データの表示

第III部 データ・ウェアハウスのレポート作成

7 レポートおよび分析のSQL

- ビジネス問合せに応答するSQLアナリティック機能の使用

- ROLLUP関数を使用したレポートへの合計の追加方法

- ROLLUP関数を使用するとき

- 例: ROLLUP関数の使用

- CUBE関数を使用した異なるレベルでの合計の分割方法

- CUBE関数を使用するとき

- 例: CUBE関数の使用

- GROUPING関数を使用した小計の追加方法

- GROUPING関数を使用するとき

- 例: GROUPING関数の使用

- GROUPING SETS関数を使用した集計の結合方法

- GROUPING SETS関数を使用するとき

- 例: GROUPING SETS関数の使用

- RANK関数を使用したランキングの計算方法

- RANK関数を使用するとき

- 例: RANK関数の使用

- 合計に対する相対的な寄与率の計算方法

- 例: 総計に対する相対的な寄与率の計算

- ウィンドウ関数を使用した行間計算の実行方法

- 例: 行間計算の実行

- ウィンドウ関数を使用した移動平均の計算方法

- 例: 移動平均の計算

- パーティション外部結合を使用したスパースなデータの処理

- パーティション外部結合を使用するとき

- 例: パーティション外部結合の使用

- ビジネス問合せを単純化するWITH句の使用

- WITH句を使用するとき

- 例: WITH句の使用

第IV部 データ・ウェアハウスの管理

8 データ・ウェアハウスのリフレッシュ

- データ・ウェアハウスのリフレッシュについて

- 例: データ・ウェアハウスのリフレッシュ

- ローリング・ウィンドウを使用したデータのオフロード

- 例: ローリング・ウィンドウの使用

9 データ・ウェアハウスの操作の最適化

- システムのオーバーロードの回避

- システム・パフォーマンスの監視

- パラレル実行パフォーマンスの監視

- I/Oの監視

- データベース・リソース・マネージャの使用

- 索引およびマテリアライズド・ビューの使用の最適化

- 例: SQLアクセス・アドバイザを使用した索引およびマテリアライズド・ビューの使用の最適化

- 記憶域要件の最適化

- データ圧縮による記憶域の改善

10 パフォーマンス・ボトルネックの排除

- SQLの効率的な実行の検証

- オプティマイザ統計の分析

- 実行計画の分析

- 例: 実行計画の出力の分析

- ヒントを使用したデータ・ウェアハウスのパフォーマンスの向上

- 例: ヒントを使用したデータ・ウェアハウスのパフォーマンスの向上

- アドバイザを使用したSQLパフォーマンスの検証

- リソース使用量の最小化によるパフォーマンスの向上

- パフォーマンスの向上: パーティション化

- パフォーマンスの向上: パーティション・プルーニング

- パフォーマンスの向上: パーティションワイズ結合

- 例: SQLアクセス・アドバイザを使用したパーティション化の評価

- パフォーマンスの向上: クエリー・リライトおよびマテリアライズド・ビュー

- パフォーマンスの向上: 索引

- パフォーマンスの向上: 圧縮

- パフォーマンスの向上: DBMS_COMPRESSIONパッケージ

- パフォーマンスの向上: CREATE TABLEおよびALTER TABLEのtable_compress句

- 最適なリソースの使用

- パラレル実行でのパフォーマンスの最適化

- パラレル実行の動作方法

- 並列度の設定

- 例: 並列度の設定

- 待機イベントについて

11 データ・ウェアハウスのバックアップおよびリカバリ

- データ・ウェアハウスのバックアップおよびリカバリの処理方法

- バックアップおよびリカバリの計画とベスト・プラクティス

- ベスト・プラクティスA: ARCHIVELOGモードの使用

- 停止時間の許容について

- ベスト・プラクティスB: RMANの使用

- ベスト・プラクティスC: 読取り専用の表領域の使用

- ベスト・プラクティスD: NOLOGGING操作の計画

- 抽出、変換およびロード

- 増分バックアップ

- ベスト・プラクティスE: すべての表領域の重要度が同等でない場合

12 データ・ウェアハウスのセキュリティ

- データ・ウェアハウスのセキュリティについて

- データ・ウェアハウスのセキュリティの必要性について

- データ・ウェアハウスのセキュリティのロールおよび権限の使用

- データ・ウェアハウスの仮想プライベート・データベースの使用

- 仮想プライベート・データベースの動作方法

- Oracle Label Securityの概要

- Oracle Label Securityの動作方法

- データ・ウェアハウスによりラベルを利用する方法

- データ・ウェアハウスのファイングレイン監査の概要

- データ・ウェアハウスの透過的データ暗号化の概要

索引

Oracle® Database

2日でデータ・ウェアハウス・ガイド

11g リリース2(11.2)

B56298-04(原本部品番号:E25555-03)

2012年2月

Oracle Database 2日でデータ・ウェアハウス・ガイド, 11gリリース2(11.2)

B56298-04

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

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

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

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

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

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

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

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

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

はじめに

ここでは、次の項目について説明します。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Database 2日でデータ・ウェアハウス・ガイド』は、Oracle Databaseを使用して日常の一般的なデータ・ウェアハウスのタスクを実行するユーザーを対象としています。コンピュータの基本的な知識があり、『Oracle Database 2日でデータベース管理者』を参照済であることが主な前提条件です。

このガイドは、特に次のようなユーザーを対象としています。

- データ・ウェアハウスの管理スキルを習得する必要があるOracle DBA

- データ・ウェアハウスの基礎知識はある程度あるが、Oracle Databaseを初めて使用するDBA

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

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

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 Database 2日でデータベース管理者』

- 『Oracle Databaseデータ・ウェアハウス・ガイド』

- 『Oracle Database管理者ガイド』

- 『Oracle Warehouse Builder Concepts』

- 『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』

- 『Oracle Warehouse Builderソースおよびターゲット・ガイド』

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第I部

データ・ウェアハウスの構築

第I部では、データ・ウェアハウスの構築方法について説明します。内容は次のとおりです。

- 第1章「データ・ウェアハウスの概要」

- 第2章「データ・ウェアハウス・システムの設定」

- 第3章「データ・ソースの識別およびメタデータのインポート」

- 第4章「Oracle Warehouse Builderでのウェアハウスの定義」

1 データ・ウェアハウスの概要

データ・ウェアハウスの管理、設計および実装を行うユーザーとして、組織内のOracleデータ・ウェアハウスの操作全体を監視し、効率的なパフォーマンスを維持します。

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

- このガイドについて

- データ・ウェアハウスについて

- このガイドで説明するタスク

- データ・ウェアハウス管理用ツール

このガイドについて

『Oracle Database 2日でデータ・ウェアハウス・ガイド』では、データ・ウェアハウスを実装して管理するために必要な共通の日常のタスクを実行する方法を説明しています。このガイドの目標は、Oracle Databaseで使用可能なデータ・ウェアハウス・ソリューションの概要を示すことです。

基本的なパフォーマンス監視タスクを実行する方法を含め、データ・ウェアハウスの稼働を続けるために必要な共通の管理タスクおよび設計タスクを行う方法を説明します。

このガイドで使用する主要なインタフェースは、Oracle Enterprise Manager(Enterprise Manager)、Oracle Warehouse Builder(Warehouse Builder)およびSQL*Plusです。

参照:

- 『Oracle Enterprise Manager管理』

- 『Oracle Warehouse Builder Concepts』

- 『SQL*Plusクイック・リファレンス』

このガイドを使用する前に

このガイドを使用する前に、次の準備を実行する必要があります。

- Oracle Databaseを管理するOracle Enterprise Manager(EM)の使用方法についての理解を深めます。『Oracle Database 2日でデータベース管理者』を参照してください。

- 「データ・ウェアハウス管理用ツール」に示されている必要なツールを入手します。

このガイドの対象外

『Oracle Database 2日でデータ・ウェアハウス・ガイド』は、データ・ウェアハウスをOracle Databaseに実装するための完全なガイドではありません。このガイドの目的は、タスクがタスク指向方式で実行される理由と時期を説明することです。必要に応じて、現行のタスクを理解して完了するために必要な概念を説明します。

機能および使用上の詳細な手順に関する完全な概念の情報は、次の適切なドキュメントを参照してください。

- 『Oracle Databaseデータ・ウェアハウス・ガイド』

- 『Oracle Warehouse Builderソースおよびターゲット・ガイド』

- 管理タスクについては、『Oracle Database管理者ガイド』を参照してください。

- データ・マイニングについては、『Oracle Data Mining Concepts』を参照してください。

データ・ウェアハウスについて

データ・ウェアハウスは、問合せと分析のために設計されたリレーショナル・データベースまたは多次元データベースです。OLTPシステムのドメインであるトランザクション処理用には最適化されません。通常はデータ・ウェアハウスにより、複数のソースから導出された履歴データおよび分析データが統合されます。データ・ウェアハウスにより、トランザクション・ワークロードから分析ワークロードが分割され、組織が複数のソースからデータを統合できるようにします。

データ・ウェアハウスには通常、複数月または複数年のデータが格納されており、履歴の分析をサポートします。データ・ウェアハウス内のデータは通常、OLTPアプリケーション、メインフレーム・アプリケーション、または外部データのプロバイダなどのような1つ以上のデータ・ソースから抽出、変換およびロード(ETL)の各プロセスを介してロードされます。

データ・ウェアハウスのユーザーは、多くの場合、時間に関連するデータの分析を実行します。例として、昨年の連結売上高、在庫分析、製品別収益および顧客別収益があります。より高度な分析に、傾向分析とデータ・マイニングがあり、既存のデータを使用して傾向または今後を予測します。一般にデータ・ウェアハウスでは、ビジネス・インテリジェンス環境の基盤を提供します。

このガイドでは、スター・スキーマなど、リレーショナル実装について説明しています。

参照:
多次元データ・ウェアハウスの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

データ・ウェアハウスの主な特性

データ・ウェアハウスの主な特性は次のとおりです。

- データの一部は、単純化およびパフォーマンスの向上のために非正規化されています。

- 大量の履歴データが使用されます。

- 問合せにより大量のデータを取得することがあります。

- 計画済問合せと非定型問合せの両方とも一般的です。

- データのロードは制御されます。

一般的に、データ・ウェアハウスを正常に動作させるためには、高いデータ・スループットによる高速な問合せのパフォーマンスが重要となります。

Oracleデータ・ウェアハウスの一般的なタスク

Oracleデータ・ウェアハウス管理者または設計者として、次のタスクを行うことが予想されます。

- データ・ウェアハウスとして使用するためのOracle Databaseの構成

- データ・ウェアハウスの設計

- データベース・ソフトウェアおよびデータ・ウェアハウス・ソフトウェアの新規リリースへのアップグレードの実行

- スキーマ・オブジェクトの管理(表、索引およびマテリアライズド・ビューなど)

- ユーザーおよびセキュリティの管理

- 抽出、変換およびロード(ETL)の各プロセスに使用するルーチンの開発

- データ・ウェアハウス内のデータに基づいたレポートの作成

- 必要に応じたデータ・ウェアハウスのバックアップおよびリカバリの実行

- データ・ウェアハウスのパフォーマンスの監視と必要に応じた予防処理または修正処理

中小規模のデータ・ウェアハウス環境では、これらのタスクを単独で実行する可能性があります。大企業のような環境の場合、ジョブはデータベース・セキュリティまたはデータベースのチューニングなどの専門を持つ数名のDBAおよび設計者に分割されます。

このガイドで説明するタスク

このガイドでは、次のタスクについて説明します。

1. データ・ウェアハウスとして使用するためのOracle Databaseを構成します。
第2章「データ・ウェアハウス・システムの設定」を参照してください。この項では、このガイド全体の演習で参照されるデモンストレーションにアクセスする方法についても説明されています。

2. データを統合する最初のステップを実行します。
第3章「データ・ソースの識別およびメタデータのインポート」の説明に従います。

3. ウェアハウス内のターゲット・オブジェクトの定義を開始します。
ターゲット・ウェアハウスの外部表、ディメンションおよびキューブを定義する方法については、第4章「Oracle Warehouse Builderでのウェアハウスの定義」を参照してください。

4. ターゲットにデータを抽出、変換およびロードする計画を定義します。
手順2で指定したソースからデータを抽出し、そのデータを変換し、次に手順3で設計したターゲットにデータをロードするETLロジックを定義する方法については、第5章「ETLロジックの定義」を参照してください。

5. ターゲット・スキーマへ配布し、ETLロジックを実行します。
マッピングからのコードを使用してターゲット・スキーマを準備する方法、およびその後にそのコードを実行する方法については、第6章「ターゲット・スキーマへの配布およびETLロジックの実行」を参照してください。

6. 効率的なSQLを書きます。
第7章「レポートおよび分析のSQL」を参照し、説明されているタスクを完了します。この項では、効率的なSQLを書く方法について説明されています。

7. データ・ウェアハウスをリフレッシュします。
第8章「データ・ウェアハウスのリフレッシュ」を参照し、説明されているタスクを完了します。

8. 操作を最適化します。
第9章「データ・ウェアハウスの操作の最適化」を参照し、説明されているタスクを完了します。

9. パフォーマンス・ボトルネックを排除します。
第10章「パフォーマンス・ボトルネックの排除」を参照し、説明されているタスクを完了します。

10. データ・ウェアハウスのバックアップおよびリカバリの基本の一部を確認します。
データ・ウェアハウスをバックアップおよびリカバリする方法に関するいくつかの考慮事項については、第11章「データ・ウェアハウスのバックアップおよびリカバリ」を参照してください。

11. データ・ウェアハウスのセキュリティの基本の一部を確認します。
安全なデータ・ウェアハウスを作成する方法に関するいくつかの考慮事項については、第12章「データ・ウェアハウスのセキュリティ」を参照してください。

データ・ウェアハウス管理用ツール

このガイドの手順では、データ・ウェアハウスで目標を達成するための次の製品、ツールおよびユーティリティが示されます。これらが必要となる場合もあります。

- Oracle Universal Installer
Oracle Universal Installer(OUI)により、Oracleソフトウェアおよびオプションをインストールします。これによりDatabase Configuration Assistant(DBCA)が自動的に開始され、データベースがインストールされます。OUIおよびDBCAはOracle Databaseに含まれます。オプションの情報は、Oracle Universal Installerユーザーズ・ガイドfor Windows and UNIXを参照してください。

- Oracle Enterprise Manager
データベースを管理する主要なツールはWebベースのインタフェースであるOracle Enterprise Managerです。Oracleソフトウェアのインストール、データベースの作成またはアップグレード、およびネットワークの構成後、データベースを管理するOracle Enterprise Managerを使用できます。さらに、Oracle Enterprise Managerではパフォーマンス・アドバイザのインタフェース、およびSQL*Loader、Recovery ManagerなどのOracleユーティリティのインタフェースを使用できます。このガイドの記載よりもさらに詳細な内容を確認する場合は、『Oracle Enterprise Manager管理』を参照してください。

- Oracle Warehouse Builder
データ・ウェアハウスの移入および保持のための主要な製品であるOracle Warehouse Builderによって、単一の製品内でのETL、データ品質管理およびメタデータ管理が提供されます。

Warehouse Builderには、Oracle Databaseに格納される統合リポジトリが含まれています。Warehouse Builderは、Oracle Databaseの機能を使用して、Oracle DatabaseターゲットへのロードおよびOracle Databaseターゲットのメンテナンスに適したコードを生成します。詳細および総合的な手順は、『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』を参照してください。

- Oracle Tuning Pack
Oracle Tuning Packでは、データベース全体のチューニング処理を自動化する一連のテクノロジが提供されるため、データベースの管理コストが大幅に削減され、パフォーマンスと信頼性が向上します。このガイドで使用されているOracle Tuning Packの主要な機能は、SQLアクセスおよびSQLチューニング・アドバイザです。『Oracle Databaseライセンス情報』および『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

注意:
この項でリストされているOUIおよびWarehouse Builderは、Oracle Databaseに含まれています。Warehouse Builderの一部のデータ品質機能には、追加のライセンスが必要です。Oracle Tuning Packには、追加のライセンスが必要です。

2 データ・ウェアハウス・システムの設定

この章では、データ・ウェアハウス環境を最初に構成する方法を説明します。この付録には、次の項があります。

- データ・ウェアハウス・システムを設定する一般的な手順

- 環境の準備

- データ・ウェアハウスのデータベースの設定

- Oracle Warehouse Builderへのアクセス

データ・ウェアハウス・システムを設定する一般的な手順

この項にある手順では、データ・ウェアハウスとして使用するためのOracleデータベースを構成する方法を説明します。その後は、Oracle Warehouse Builder(OWB)を構成し、Oracle Databaseを利用してデータ管理方針設計用のグラフィカル・ユーザー・インタフェースを提供します。

データ・ウェアハウス・システムをセットアップする手順

1. 「環境の準備」の説明に従って、ハードウェアのサイジングおよび構成を行います。

2. Oracle Databaseソフトウェアをインストールします。インストール手順については、『Oracle Database 2日でデータベース管理者』または『Oracle Databaseインストレーション・ガイドfor Linux』など、使用するプラットフォームのインストレーション・ガイドを参照してください。

3. 「データ・ウェアハウスのデータベースの設定」の説明に従って、データベースをデータ・ウェアハウスとして使用できるように構成します。

4. Oracle Warehouse Builderソフトウェアにアクセスします。
「Oracle Warehouse Builderへのアクセス」の説明に従います。その後は、デモンストレーションをインストールし、データ・ウェアハウスの一般的なタスクをWarehouse Builderで実行する方法を学習できます。

環境の準備

データ・ウェアハウスのアーキテクチャの基本的な構成要素は、オンライン・トランザクション処理(OLTP)システムの基本的な構成要素に似ています。ただし、データのサイズと量のため、データ・ウェアハウスのハードウェア構成およびデータ・スループットの要件は固有のものとなります。データ・ウェアハウスのサイジングは、システムに必要なスループットが起点になります。サイジング時には、次の基準を1つ以上使用します。

- ピーク時に問合せによりアクセスされるデータ量および許容できるレスポンス時間。

- 一定期間内にロードされるデータ量。

一般的に、どの特定の時間でも必要とする最も高いスループットを見積もる必要があります。

ハードウェア・ベンダーによって適切なデータ・ウェアハウス・アプリケーション設定が推奨されるため、サイジングに役立ちます。詳細は、任意のハードウェア・ベンダーにご相談ください。

適切なハードウェア設定

データ・ウェアハウスのパフォーマンスを最大限にするには、適切なサイジングと安定したハードウェア構成が必要です。次の項では、適切な構成に重要なポイントを説明します。

- 必要なCPU数およびクロック・スピードについて

- 必要なメモリーについて

- 必要なディスク数について

- 十分なI/O帯域幅を判断する方法について

必要なCPU数およびクロック・スピードについて

中央演算装置(CPU)はデータ・ウェアハウスの計算機能に使用されます。データ・ウェアハウスの操作を実行するには、十分な処理能力を持つCPUが必要です。パラレル操作は、それと同等な数のシリアル操作よりもCPUに負担がかかります。

必要なCPU数は、見積もった最も高いスループットを目安に使用します。大まかな見積りとして、次の公式を使用します。

<number of CPUs> = <maximum throughput in MB/s> / 200

この公式を使用する場合は、CPUが1秒間に約200MBまで耐えられることが前提になります。たとえば、1秒間に1200MBの最高スループットが必要な場合、<number of CPUs> = 1200/200 = 6 CPUがシステムに必要です。このシステムは、6つのCPUを持つ1台のサーバー構成で処理できます。2ノード・クラスタ・システムであれば、両方のノードに3つのCPUを使用して構成できます。

必要なメモリーについて

データ・ウェアハウスのメモリーは、大規模なソートなどのメモリーに負担をかける処理を行う際に特に重要になります。大部分の問合せは大容量のデータにアクセスするため、データ・キャッシュへのアクセスはデータ・ウェアハウスにとっては重要ではありません。データ・ウェアハウスには、重要なOLTPアプリケーションと同じメモリー要件はありません。

CPU数は必要なメモリー容量のよいガイドラインになります。次の単純な公式を使用すると、選択したCPUで必要なメモリー容量を計算できます。

<amount of memory in GB> = 2 * <number of CPUs>

たとえば、6つのCPUを持つシステムが必要とするメモリー容量は2 * 6 = 12 GBになります。大部分の一般的なサーバーはこの要件を満たしています。

必要なディスク数について

データ・ウェアハウス環境での一般的な問題は、必要とする最大容量に基づいた記憶領域のサイジングです。記憶領域要件に排他的に基づいたサイジングは、スループットのボトルネックを作成する傾向があります。

必要なディスク・アレイの数を知るために、必要とする最大スループットを使用します。また、ディスク・アレイが耐えられるスループットを知るために、記憶領域プロバイダの指定を使用します。記憶領域プロバイダはGb/秒で測定され、最初のスループットの見積りはMB/秒に基づいていることに注意してください。平均的なディスク・コントローラの最大スループットは2Gb/秒で、これは持続可能なスループットでは約(70% * 2 Gbit/s) /8 = 180 MB/sに相当します。

必要なディスク・アレイ数を決定するには、次の公式を使用します。

- <number of disk controllers> = <throughput in MB/s> / <individual controller throughput in MB/s>

たとえば、スループットが1秒当たり1200MBのシステムでは、1200 / 180 = 7 ディスク・アレイとなり、少なくとも7つのディスク・アレイが必要となります。

必要なスループットを維持するために十分な物理ディスクがあるか確認してください。ディスクのスループット数をディスク・ベンダーに尋ねてください。

十分なI/O帯域幅を判断する方法について

エンドツーエンドのI/Oシステムは、CPUおよびディスクを含んだコンポーネントで構成されます。バランスのよくとれたI/Oシステムには、I/Oシステムのすべてのコンポーネントに対して同等の帯域幅が必要です。これらのコンポーネントには次が含まれます。

- サーバーおよび記憶領域間のコネクタであるホスト・バス・アダプタ(HBA)。

- サーバー間およびストレージ・エリア・ネットワーク(SAN)またはネットワーク・アタッチ・ストレージ(NAS)間のスイッチ。

- ネットワーク接続用のイーサネット・アダプタ(GigE NICまたはInfiniband)。Oracle Real Application Clusters(Oracle RAC)環境では、I/Oスループットのシステムのサイジング時には含めないノード間のインターコネクト用に追加のプライベート・ポートが必要です。インターコネクトは、ノード間のパラレル実行などのファクタを考慮に入れ、個々にサイジングする必要があります。

- 個別のコンポーネントを接続するワイヤ。

各コンポーネントは、バランスのよくとれたI/Oシステムにするために十分なI/O帯域幅を提供する必要があります。見積もった最初のスループットおよびベンダーによるハードウェア仕様は、必要な個々のコンポーネントの量を決定する基準になります。ベンダーのビット単位で表現した最大スループット数を、バイト単位の持続可能なスループット数に変換するには、表2-1の換算を使用してください。

表2-1 スループット・パフォーマンスの変換

コンポーネント

ビット

1秒当たりのバイト数

HBA

2GB

200MB

16ポート・スイッチ

8×2GB

1200MB

Fibre Channel

2GB

200MB

GigE NIC

1GB

80MB

Inf-2Gビット

2GB

160MB

十分なI/O帯域幅を確保するために十分なコンポーネントを使用することに加え、ディスク上でのデータのレイアウトが成功と失敗を分ける鍵となります。すべてのディスク・アレイに対して十分なスループットを持つシステムを構成しても、問合せが取得するデータが1つのディスク上にある場合は、必要なスループットを得ることができません。これは、ディスクが1つしかないことがボトルネックとなるためです。このような状況を避けるためには、できるかぎり多くのディスク、理想はすべてのディスクへデータをストライプ化します。1MBに対して256KBのストライプのデータは、マルチブロック読取り操作および複数のディスクへのデータの振り分け間でのよいバランスを提供します。

データ・ウェアハウスのハードウェア構成の検証

Oracle Databaseのインストールの前に、ハードウェアおよびオペレーティング・システムのレベルで設定を検証してください。必要なスループットとパフォーマンスがオペレーティング・システムから得られない場合、Oracle Databaseはユーザーの要件に合せて実行できません。スループットを検証するためのツールは、ddユーティリティと、オラクル社が提供するOrionの2つがあります。

ddユーティリティについて

UNIXまたはLinuxでオペレーティング・システムのスループットを検証する基本方法は、ddユーティリティを使用することです。ddユーティリティは、UNIXの一般的なプログラムであり、このユーティリティの主な目的は、生データの低レベル・コピーおよび変換です。ddユーティリティにはオーバーヘッドがほとんどないため、その出力からは信頼できる測定値が得られます。Oracle Databaseは、ddユーティリティが実現する最大スループットの約90パーセントに到達できます。

例: ddユーティリティの使用

次は、ddの使用に最も重要なオプションです。

bs=BYTES: Read BYTES bytes at a time; use 1 MB
count=BLOCKS: copy only BLOCKS input blocks
if=FILE: read from FILE; set to your device
of=FILE: write to FILE; set to /dev/null to evaluate read performance;
write to disk would erase all existing data!!!
skip=BLOCKS: skip BLOCKS BYTES-sized blocks at start of input

Oracle Databaseが達成可能な最大スループットを見積もるため、典型的なデータ・ウェアハウス・アプリケーションのワークロード(大規模かつ、ランダムで連続したディスク・アクセスによる)を模倣します。

次のddコマンドは合計2GBを読み取る2つのデバイスに対してランダムで連続したディスク・アクセスを実行します。スループットは次のコマンドを終了するのに必要な時間によって分けられた2GBです。

dd bs=1048576 count=200 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=200 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=400 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=600 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 skip=800 if=/raw/data_1 of=/dev/null &
dd bs=1048576 count=200 if=/raw/data_2 of=/dev/null &
dd bs=1048576 count=200 skip=200 if=/raw/data_2 of=/dev/null &
dd bs=1048576 count=200 skip=400 if=/raw/data_2 of=/dev/null &
dd bs=1048576 count=200 skip=600 if=/raw/data_2 of=/dev/null &
dd bs=1048576 count=200 skip=800 if=/raw/data_2 of=/dev/null &

検証では、データベースの記憶領域に含む予定のすべての記憶領域装置を対象としてください。クラスタ環境を構成する場合は、それぞれのノードからddコマンドを実行します。

Orionユーティリティについて

Orionはオラクル社が提供するツールで、スループットの測定を目的として、データベース・システム上の代表的なワークロードを模倣します。ddユーティリティと比較すると、Orionには次の利点があります。

- Orionのシミュレーションはデータベースが生成するワークロードに似ています。

- Orionを使用すると、1つのシミュレーションで高い信頼性の書取りおよび読取りシミュレーションを実行できます。

オラクル社はデータベースがすでにインストールされている場合でも、最大の達成可能なスループットを検証するためにOrionの使用をお薦めします。

次はサポートされるI/Oワークロードのタイプです。

- 小規模およびランダム

- 大規模および連続的

- 大規模およびランダム

- 混合ワークロード

各タイプのワークロードでOrionは1秒当たりのMB、1秒当たりのI/OおよびI/O待機時間などのパフォーマンス・メトリクスを計測するためのI/Oロードの異なるレベルで検証を実行できます。データ・ウェアハウス・ワークロードは複数のプロセスによって発行された連続するI/Oスループットによって一般的に特徴づけられています。構築するシステムのタイプに応じて異なるI/Oシミュレーションを実行できます。例は次のとおりです。

- ユーザーまたはアプリケーションがシステムに問い合せる場合の毎日のワークロード

- ユーザーがシステムにアクセスするまたはしない場合のデータ・ロード

- 索引およびマテリアライズド・ビューの構築

- バックアップ操作

参照:

- 詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

データ・ウェアハウスのデータベースの設定

環境設定およびOracle Databaseソフトウェアのインストール後、データベース・パラメータが正しく設定されていることを確認します。設定する必要があるデータベース・パラメータは多くありません。

一般的なガイドラインとして、特に理由がないかぎり、データベース・パラメータは変更しないでください。データ・ウェアハウスの設定には、Oracle Enterprise Managerを使用します。様々なパラメータ設定を表示するには、「データベース」ページに移動して「サーバー」をクリックします。「データベース構成」で「メモリー・パラメータ」または「すべての初期化パラメータ」をクリックします。

メモリー管理パラメータの設定方法

Oracle Databaseメモリーには、次のコンポーネントがあります。

- 共有メモリー: システム・グローバル領域(SGA)とも呼ばれます。Oracleインスタンスで使用されるメモリーです。

- セッションベース・メモリー: データベースのセッションに占有されるメモリーで、プログラム・グローバル領域(PGA)とも呼ばれています。セッションベース・メモリーはソートや集計などのデータベース操作の実行に使用されます。

Oracle Databaseは2つのメモリー領域のメモリー・コンポーネントの配布を自動的にチューニングします。次に示す相互に排他的な2つのオプションのいずれかを選択できます。

- MEMORY_TARGETおよびMEMORY_MAX_TARGETを設定します。

- SGA_TARGETおよびPGA_AGGREGATE_TARGETを設定します。
最初のオプションを選択した場合、他のパラメータを設定する必要はありません。データベースによって、すべてのメモリーが管理されます。2番目のオプションを選択した場合は、SGAとPGAのサイズを指定する必要があります。その他の設定は、データベースによって行われます。

PGA_AGGREGATE_TARGETパラメータはすべてのセッションの合計PGAが使用するターゲット・メモリー容量です。まずは、次の公式を使用してPGA_AGGREGATE_TARGET値を定義します。

- PGA_AGGREGATE_TARGET = 3 * SGA_TARGET
このPGA_AGGREGATE_TARGETをメモリーに適用するための十分な物理メモリーがない場合は、PGA_AGGREGATE_TARGETの値を小さくします。

- MEMORY_TARGETおよびMEMORY_MAX_TARGET
MEMORY_TARGETパラメータによってターゲットのメモリー・サイズを設定でき、関連した初期化パラメータMEMORY_MAX_TARGETによって最大ターゲット・メモリー容量を設定できます。データベースは、システム・グローバル領域(SGA)および集計プログラム・グローバル領域(PGA)間の要件に従ってメモリーを再分配し、ターゲット・メモリー・サイズに対してチューニングします。ターゲット・メモリー初期化パラメータは動的であるため、データベースの再起動なしにいつでもターゲット・メモリー・サイズを変更できます。最大メモリー・サイズは上限として機能するため、ターゲット・メモリー・サイズを非常に高い値に設定してしまうことはありません。また特定のSGAコンポーネントが簡単に縮小できないこと、または最小サイズで保持される必要があるため、ターゲット・メモリー・サイズを過度に小さく設定してしまうことも防止します。

例: 初期化パラメータの設定

次で示すように、ALTER SYSTEMの発行により初期化パラメータの設定ができます。

ALTER SYSTEM SET SGA_TARGET = 1024M;

重要な他の初期化パラメータの設定

初めてデータ・ウェアハウスを使用する際は、Database Configuration Assistant(DBCA)の実行時に選択できるデータ・ウェアハウス・テンプレート・データベースが便利です。ただし、次の初期化パラメータを考慮すれば、どのデータベースでもかまいません。

- COMPATIBLE
COMPATIBLEパラメータは以前のリリースに対してデータベースが持つ互換性のレベルを識別します。最新機能を活用するには、COMPATIBLEパラメータでデータベースのリリース番号に設定します。

- OPTIMIZER_FEATURES_ENABLE
クエリー・リライトなどの上位のコストベース・オプティマイザ機能を活用するには、OPTIMIZER_FEATURES_ENABLEパラメータがデータベースの現行バージョンの値に設定されていることを確認します。

- DB_BLOCK_SIZE
DB_BLOCK_SIZEパラメータのデフォルト値は8KBで、この値はデータ・ウェアハウスのほとんどの要件に適しています。表圧縮を使用する場合は、より大きなブロック・サイズを指定することを検討してください。

- DB_FILE_MULTIBLOCK_READ_COUNT
DB_FILE_MULTIBLOCK_READ_COUNTパラメータを使用すると、単一オペレーティング・システムの読取りコールでデータベース・ブロックの読取りができます。データ・ウェアハウスの一般的なワークロードは多くの連続したI/Oで構成されているため、多数の小さいI/Oではなく、少数の大きいI/Oを活用できるようにします。このパラメータを設定するときは、オペレーティング・システムのブロック・サイズと最大I/Oサイズを考慮して、次の公式を使用します。

DB_FILE_MULTIBLOCK_READ_COUNT * DB_BLOCK_SIZE =
<maximum operating system I/O size>

最大のオペレーティング・システムのI/Oサイズは64KBから1MBの間で変化します。

- PARALLEL_MAX_SERVERS
PARALLEL_MAX_SERVERSパラメータは、パラレル実行の使用可能な最大プロセス数のリソース制限を設定します。パラレル操作には、操作のあらゆる表に属性を付与する最大並列度(DOP)として問合せサーバーのプロセス数が最大2倍必要です。

Oracle Databaseはほとんどのシステムにとって十分なデフォルト値をPARALLEL_MAX_SERVERSパラメータに設定します。PARALLEL_MAX_SERVERSパラメータのデフォルト値は次のとおりです。

(CPU_COUNT x PARALLEL_THREADS_PER_CPU x (2 if PGA_AGGREGATE_TARGET > 0; otherwise 1) x 5)

上位のDOP属性を持つ表のパラレル問合せにはこの値は十分ではない可能性があります。オラクル社は上位のDOPの問合せを実行するユーザーには、PARALLEL_MAX_SERVERSを次のように設定することをお薦めします。

2 x DOP x <number_of_concurrent_users>

たとえば、PARALLEL_MAX_SERVERSパラメータに64を設定することで、各問合せは各セットの8つのDOPを持つ2つのスレーブ・セットを使用することを想定し、同時に4つのパラレル問合せを実行できます。

ハードウェア・システムがCPUバインドでもI/Oバインドでもない場合、問合せサーバー・プロセスを追加することによって、システムに同時パラレル実行ユーザーの数を増やすことができます。一方システムがCPUバインドまたはI/Oバインドになる場合、同時ユーザーの追加はすべてのパフォーマンスに弊害をもたらします。PARALLEL_MAX_SERVERSパラメータを慎重に設定することが、同時パラレル操作数の制限に効果的な方法です。

- PARALLEL_ADAPTIVE_MULTI_USER
TRUEまたはFALSEになるPARALLEL_ADAPTIVE_MULTI_USERパラメータは、現行のワークロードに応じて特定の文の並列度を動的に決定するためのアルゴリズムをサーバーが使用するどうかを定義します。この機能を使用するには、PARALLEL_ADAPTIVE_MULTI_USERをTRUEに設定します。

- QUERY_REWRITE_ENABLED
マテリアライズド・ビューに対してクエリー・リライトを利用するには、QUERY_REWRITE_ENABLEDパラメータをTRUEに設定する必要があります。このパラメータのデフォルトはTRUEです。

- QUERY_REWRITE_INTEGRITY
QUERY_REWRITE_INTEGRITYパラメータのデフォルトはENFORCEDです。データベースは、有効になっている検証された主キー制約、一意キー制約、および外部キー制約を基準とする場合、最新のマテリアライズド・ビューに対してのみクエリー・リライトを行います。

TRUSTEDモードでは、オプティマイザはマテリアライズド・ビューのデータが現行であり、ディメンションで宣言された階層関係およびRELY制限が正確であるものとみなします。

- STAR_TRANSFORMATION_ENABLED
最適化されたスター型変換を利用するには、STAR_TRANSFORMATION_ENABLEDパラメータをTRUEに設定します。

Oracle Warehouse Builderへのアクセス

Oracle Warehouse Builder(OWB)を使用すると、従来のデータ・ウェアハウスを含む様々なタイプのデータ管理計画を設定および配布できます。

OWBを有効にする手順

1. Oracle DatabaseのEnterprise EditionまたはStandard Editionのいずれかにアクセスしていることを確認します。
Oracle Database 11gには、Warehouse Builderサーバー・コンポーネントが事前にインストールされています。また、Warehouse Builderリポジトリのスキーマも含まれています。

2. Oracle DatabaseにインストールされているデフォルトのWarehouse Builderスキーマを使用するには、まず、次のようにスキーマのロックを解除します。
SYSまたはSYSDBAユーザーとしてSQL*Plusに接続し、次のコマンドを入力します。

SQL> ALTER USER OWBSYS ACCOUNT UNLOCK;

SQL> ALTER USER OWBSYS IDENTIFIED BY owbsys_passwd;

3. Warehouse Builderのデザイン・センターを起動します。
Windowsの場合、「スタート」→「プログラム」→「Oracle」→「Warehouse Builder」を選択後、「デザイン・センター」を選択します。

UNIXおよびLinuxの場合、owb home/owb/bin/unixに移動し、owbclient.shを実行します。

4. ワークスペースを定義し、ユーザーをワークスペースに割り当てます。
単一のWarehouse Builderリポジトリでは、関連付けられているオブジェクト上で作業している一連のユーザーに対応している各ワークスペースで、複数のワークスペースを定義できます。たとえば、開発、テストおよび本番などの各環境に対してワークスペースを作成できます。

簡略化するために、MY_WORKSPACEという1つのワークスペースを作成し、ユーザーを割り当てます。

「デザイン・センター」ダイアログ・ボックスで、「詳細の表示」をクリックした後、「ワークスペース管理」をクリックします。

「リポジトリ・アシスタント」が表示されます。

プロンプトに従い、「リポジトリ・アシスタント」でデフォルト設定を受け入れ、ワークスペースを作成し、ユーザーをワークスペース所有者として割り当てます。

5. 作成したユーザー名およびパスワードで「デザイン・センター」にログインします。

参照:
『Oracle Warehouse Builderインストレーションおよび管理ガイドfor Windows and Linux』

Oracle Warehouse Builderデモンストレーションのインストール

ここからは、Oracle Warehouse Builder用のOracle By Example(OBE)Seriesの演習を使用して、複数のフラット・ファイル・ソースのデータの統合、データの変換および新規リレーショナル・ターゲットへのロード方法について説明します。

演習および例は、Oracle Technology Network(OTN)(http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/10g/r2/owb/owb10gr2_obe_series/owb10g.htm)で入手できます。このデモンストレーションには、製品への理解を深めるために多様なWarehouse Builderオブジェクトを作成するフラット・ファイル・データおよびスクリプトが用意されています。OBEのページでは、OWBの追加情報および演習に関する最新情報が提供されています。

このガイドに示されているWarehouse Builder演習を実行する手順

1. デモンストレーションをダウンロードします。

- OTNの次の場所から、OWBの例の場所にアクセスします。
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/10g/r2/owb/owb10gr2_obe_series/owb10g.htm

- 最新リリースのOracle By Example(OBE)セットのリンクをクリックします。

デモンストレーションは、owbdemo_files.zipというZIPアーカイブ内の一連のファイルです。

このZIPアーカイブには、SQLスクリプト、値がカンマ区切りされる形式の2つのファイルおよびTclで記述されたスクリプトが含まれます。

2. (オプション)同じリンクから、XSALES表データが含まれるxsales.zipファイルをダウンロードします。

3. スクリプトowbdemoinit.tclを編集します。
スクリプトowbdemoinit.tclによって、他のTCLスクリプトで使用される変数を定義および設定します。次の変数を編集して、コンピュータ環境の値と一致させます。

- set tempspace TEMP

- set owbclientpwd workspace_owner

- set sysuser sys

- set syspwd pwd

- set host hostname

- set port portnumber

- set service servicename

- set project owb_project_name

- set owbclient workspace_owner

- set sourcedir drive:/newowbdemo

- set indexspace USERS

- set dataspace USERS

- set snapspace USERS

- set sqlpath drive:/oracle/11.1.0/db_1/BIN

- set sid servicename

4. Warehouse Builderスクリプト・ユーティリティおよびOMB PlusからTclスクリプトを実行します。
Windowsの場合、「スタート」→「プログラム」→「Oracle」→「Warehouse Builder」を選択後、「OMB*Plus」を選択します。

UNIXの場合、owb home/owb/bin/unixに移動し、OMBPlus.shを実行します。

OMB+>プロンプトでは、次のコマンドを入力してスクリプトを含むディレクトリに移動します。

cd drive:\\newowbdemo\\

次のコマンドを入力して、すべてのTclスクリプトを必要な順序で実行します。

source loadall.tcl

5. デザイン・センターを起動し、スクリプトowbdemoinit.tclで指定した資格証明を使用して、ワークスペース所有者としてログインします。

6. デモンストレーションに従い、Warehouse Builderクライアントが正常に設定されたことを確認します。
デザイン・センターのロケーション・ナビゲータで、「ロケーション」ノードを展開します。「データベース」の展開後、「Oracle」を展開します。「Oracle」ノードには次の場所が含まれます。

OWB_REPOSITORY

SALES_WH_LOCATION

Warehouse Builderデモンストレーションを正常にインストールすると、デザイン・センターがEXPENSE_WHというOracleモジュールとともに表示されます。

3 データ・ソースの識別およびメタデータのインポート

この章では、Oracle Warehouse Builderを使用してメタデータをインポートする方法を説明します。

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

- データ・ソースの概要

- ソースからメタデータをインポートする一般的な手順

- Warehouse Builderのワークスペース、プロジェクトおよびその他のデバイスについて

- 例: フラット・ファイルからのメタデータのインポート

データ・ソースの概要

通常、データ・ウェアハウスのソース・システムになるのは、トランザクション処理のアプリケーションです。たとえば、売上分析のデータ・ウェアハウスは、現行のオーダー・アクティビティを記録しているオーダー・エントリ・システムからデータを抽出します。データ抽出プロセスの設計には問題が発生する場合があります。ソース・システムが複雑で文書化が不完全な場合、抽出するデータの決定は困難です。また、通常ソース・システムは変更できず、そのパフォーマンスまたは可用性を調整することもできません。これらの問題を処理するには、まずメタデータをインポートしてください。

メタデータはデータ・セットに与えられたオブジェクトのコンテンツを示すデータです。たとえば、表のメタデータは各列のデータ型を示します。

Oracle Databaseを使用する場合は、メタデータのインポートのためのツールとしてOracle Warehouse Builder(OWB)をお薦めします。Warehouse Builderにメタデータをインポートした後、メタデータに注釈を付けて、さらにトランザクション処理のアプリケーションから抽出計画を個別に設計できます。

ソースからメタデータをインポートする一般的な手順

メタデータをインポートする手順

1. 「Oracle Warehouse Builderへのアクセス」の指示に従います。

2. 「Oracle Warehouse Builderデモンストレーションのインストール」の説明に従ってOracle Warehouse Builderデモンストレーションをダウンロードおよびインストールします。

3. Warehouse Builderのプロジェクトを指定します。
「Warehouse Builderのワークスペース、プロジェクトおよびその他のデバイスについて」を参照してください。

4. 「例: フラット・ファイルからのメタデータのインポート」に従います。
この例では、ソース・ファイルの場所を指定する方法、および「メタデータのインポート」ウィザードを起動する方法を説明します。ファイル、表およびビューなどのデータ・オブジェクトをインポートするプロセスは同じです。したがって、この例を終了すると、Warehouse Builderにすべてのデータ・オブジェクトをインポートする一般的な方法を理解したことになります。

Warehouse Builderのワークスペース、プロジェクトおよびその他のデバイスについて

Warehouse Builderデモンストレーションをインストールして「デザイン・センター」を起動した後、ワークスペースにログインします。「デザイン・センター」の上部にユーザー名およびワークスペース名が表示されます。

ワークスペースには、関連するプロジェクトで作業する一連のユーザーが含まれます。作成するワークスペースの数を決定するためにセキュリティを考慮することは重要です。共通のモデルは、開発、テストおよび本番に個別のワークスペースを作成することです。このモデルを使用して、開発者などのユーザーによるワークスペースの開発およびテストへのアクセスを可能にしますが、本番ワークスペースへのアクセスは制限されます。

オプションで、ワークスペースをプロジェクトに分割できます。ただし実際は、ワークスペースには通常、アクティブなプロジェクトが1つのみ含まれます。これは、プロジェクトが単純に入れ物であり、セキュリティの実装またはサブジェクト指向のグループ化の確立には適さないためです。セキュリティはワークスペースを介して実装されます。後で説明するように、サブジェクト指向のグループ化の確立はモジュールを介して完了できます。

プロジェクトには、権限に関連するメタデータのセットが含まれます。したがってデータ・ウェアハウスでも、ソースおよびターゲットのすべてのメタデータを同一のプロジェクトに含めます。さらに権限の実装に必要なすべての機能、プロシージャ、変換、マッピングおよびその他のオブジェクトを含めます。プロジェクトには、Warehouse Builderに作成またはインポートできるオブジェクトの各タイプのノードが含まれます。作成またはインポートできるオブジェクトのタイプの全般を理解するために異なるノードを展開します。

このデモンストレーションでは、プロジェクト・ナビゲータが左側に表示され、2つのプロジェクトが含まれます。MY_PROJECTは事前にシードされたデフォルトのプロジェクトです。MY_PROJECTは、ワークスペース内での単一のアクティブなプロジェクトとして使用できます。デモンストレーション目的では、OWB_DEMOプロジェクトを使用します。

例: フラット・ファイルからのメタデータのインポート

この例では、フラット・ファイルからメタデータをインポートする方法について説明します。具体的には、export.csvおよびexpense_categories.csvの2つのファイルのメタデータをOWB_DEMOプロジェクトにインポートして、プロジェクト・ナビゲータの「ファイル」ノードの下に表示することが目的です。

フラット・ファイルからメタデータをインポートする手順

1. 「フラット・ファイルの場所の指定」の説明に従って、フラット・ファイルの場所を指定します。

2. 「プロジェクトでのモジュールの作成」の説明に従って、OWB_DEMOを編成し、入力フラット・ファイルのメタデータを受け取ります。

3. 「「インポート・メタデータ・ウィザード」の起動」の説明に従って、インポートするファイルを指定します。

4. 「「フラット・ファイル・サンプル・ウィザード」の使用」の説明に従って、メタデータの構成を指定します。

5. 「フラット・ファイル・データのインポート」の説明に従って、両方のフラット・ファイルのメタデータをインポートします。

フラット・ファイルの場所の指定

フラット・ファイルがある場所を指定します。

デザイン・センターの左側は「場所」と呼ばれるタブで、「場所」と呼ばれるノードが表示されます。この「ロケーション」ノードを使用してソース・データがある場所を指定します。

Warehouse Builderからアクセスできるソースおよびターゲットのタイプの全般を理解するために「ロケーション」ノードおよびその中にあるノードを開きます。

この例では、「ファイル」ノードを右クリックし、「新規ファイルシステムのロケーション」を選択してフラット・ファイルの場所を定義します。

ファイル・システムの場所を作成するダイアログ・ボックスのプロンプトに従います。定義する各場所はコンピュータのファイル・システムの特定のディレクトリに対応します。したがって、ドライブおよびディレクトリに基づいた場所の名前を付けるように考慮します。このデモンストレーションでは、場所にC_NEWOWBDEMO_SOURCEFILESという名前を付けます。

プロジェクトでのモジュールの作成

プロジェクト・ナビゲータで、OWB_DEMOを編成し、入力フラット・ファイルのメタデータを受け取ります。

データ・ウェアハウスの実装では、多数のソース・オブジェクトおよびターゲット・オブジェクトを所有する可能性があります。これらの様々なオブジェクトを編成する方法として、Warehouse Builderではモジュールを作成する必要があります。モジュールを使用すると、サブジェクト指向のグループ化を確立できます。さらに、各モジュールは、ロケーション・ナビゲータ内の作成する場所に対応します。

この例では、会社の売上データを含むモジュールを作成します。2つのフラット・ファイルに対して1つの場所のみ所有するため、プロジェクト・ナビゲータに1つのモジュールを作成します。OWB_DEMOの下の「ファイル」ノードを右クリックし、「新規フラット・ファイル・モジュール」を選択します。新規のモジュールにSALES_EXPENSESという名前を付けます。この場所には、前のステップで定義した場所、C_NEWOWBDEMO_SOURCEFILESを指定します。

「インポート・メタデータ・ウィザード」の起動

「インポート・メタデータ・ウィザード」を起動します。

モジュール「SALES_EXPENSES」を右クリックし、「新規」を選択して、「インポート・メタデータ・ウィザード」内のプロンプトに従います。ウィザード内のプロンプトは選択したモジュールのタイプによって異なり、したがってインポートするデータ・オブジェクトによっても異なります。

この例では、2つのフラット・ファイルのインポートを選択しました。「インポート・メタデータ・ウィザード」の「サマリー」ページで、ファイルの1つを選択し、次に「サンプル」を選択して「フラット・ファイル・サンプル・ウィザード」を起動します。

次のステップでは、順番に各ファイルのサンプルを作成し、このページの「終了」を選択してメタデータをインポートします。

図3-1 インポート・メタデータ・ウィザード

「図3-1 インポート・メタデータ・ウィザード」の説明

「フラット・ファイル・サンプル・ウィザード」の使用

「フラット・ファイル・サンプル・ウィザード」のプロンプトに従って、メタデータの構成を指定します。

サンプルに指定する文字の数に基づいて、ウィザードによりフラット・ファイル・データが読み込まれ、メタデータの構成のための提案が提供されます。サンプルのサイズが小さすぎる場合は、ウィザードによりデータが誤って読み込まれ、無効な提案が作成される可能性があります。それに従って、ウィザードの設定を変更および調整できます。

この例の目的のため、ウィザードによりファイルが区切られていることが正しく決定され、シングル・レコード・タイプが含まれており、キャラクタ・セットはWE8MSWIN1252です。「フラット・ファイル」ウィザードにあるすべてのデフォルト設定を受け入れます。

ウィザードによりサンプリングできる様々なタイプのファイルに精通するには、ウィザード・ページのオプションを確認してさらに知識を深めるために「ヘルプ」を選択します。

最初のフラット・ファイルをサンプリングした後、「インポート・メタデータ・ウィザード」のサマリーおよびインポートに関するページに戻り、2番目のファイルをサンプリングします。

前のファイルで行ったように、「フラット・ファイル」ウィザードのデフォルト設定を受け入れます。

フラット・ファイル・データのインポート

両方のフラット・ファイルのメタデータをインポートします。

サマリーおよびインポートに関するページに再度戻り、「終了」を選択します。

「終了」を選択する場合、ウィザードにより、データのサンプリング時に作成した選択基準に基づいてデータがインポートされます。OWB_DEMOプロジェクトの「ファイル」ノードの下にあるSALES_EXPENSESモジュールの下に、2つのカンマ区切りのファイルが表示されます。

図3-2 SOURCEフラット・ファイル・モジュール

「図3-2 SOURCEフラット・ファイル・モジュール」の説明

4 Oracle Warehouse Builderでのウェアハウスの定義

Oracle Warehouse Builder(OWB)を使用することにより、リレーショナルまたはディメンションのデータ・ウェアハウスを設計できます。

Warehouse Builderでは、物理的な実装からディメンションの設計が明示的に区別されます。簡単なクリック操作で、ディメンション・オブジェクトに対してリレーショナル実装または多次元実装のいずれかを選択できます。したがって、リレーショナル・ターゲット・ウェアハウスまたは多次元ウェアハウスとして同じディメンション・オブジェクトを実装できます。

この章では、リレーショナル・ターゲット・ウェアハウスとして実装されるディメンション・モデルを設計する方法を示します。1つのキューブと2つのディメンションで構成される小規模のデータ・ウェアハウスをモデル化します。複合のスノーフレーク・スキーマをモデル化するためにWarehouse Builderを使用できますが、このデモンストレーションの目的のために、2つのディメンションへの外部キー参照がある単一のキューブで構成される簡単なスター・スキーマをモデル化します。

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

- リレーショナル・ターゲット・ウェアハウスを定義する一般的な手順

- ウェアハウス・ターゲット・スキーマの指定

- Warehouse Builderのフラット・ファイルのソースについて

- ディメンションについて

- キューブについて

リレーショナル・ターゲット・ウェアハウスを定義する一般的な手順

この項では、リレーショナル・ターゲット・スキーマを定義する手順を示します。

リレーショナル・ターゲット・ウェアハウスを定義する手順

1. 「ウェアハウス・ターゲット・スキーマの指定」の説明に従って、スキーマをウェアハウス・ターゲット・スキーマとして指定します。

2. ウェアハウス・ターゲット・モジュールにソース・オブジェクトおよびターゲット・オブジェクトを定義またはインポートします。
一般的に、ウェアハウス・ターゲット・モジュール内のいずれかのノードを右クリックし、「新規」または「インポート」のどちらかを選択します。Warehouse Builderにより、説明のための適切なウィザードが起動されます。追加情報は、「ヘルプ」をクリックします。

ウェアハウス・ターゲット・モジュールに追加するオブジェクトのタイプは、ソース・データのタイプおよびデータ・ウェアハウスの目的によって異なります。

このガイドで示される演習を続行するには、「演習: ターゲット・モジュールへの外部表の追加」および「演習: ディメンションの理解」を参照してください。

3. ソース・オブジェクトおよびターゲット・オブジェクトを構成します。
いくつかのオブジェクトでは追加構成が必要です。ウェアハウス・モジュールに単一のオブジェクトをインポートまたは定義した後、右クリックして「構成」を選択し、設定を確認して必要に応じて変更します。

ウェアハウス・ターゲット・スキーマの指定

従来のデータ・ウェアハウスの実装内のターゲット・スキーマは通常1つのみで、これがデータ・ウェアハウスのターゲットになります。

データ・ウェアハウスのターゲット・スキーマとしてスキーマを指定する手順

1. Warehouse Builderにスキーマを登録します。
「グローバル・ナビゲータ」パネルで、「セキュリティ」ノードを開きます。「ユーザー」ノードを右クリックし、「新規ユーザー」を選択します。

「ユーザーの作成」ウィザードの「登録するDBユーザーの選択」ページで、「DBユーザーの作成」を選択し、プロンプトに従います。さらに情報が必要な場合は、「ヘルプ」をクリックするか、または[F1]キーを押します。

このデモンストレーションでは、新規スキーマを作成し、これをEXPENSE_WHと呼びます。

2. 新規スキーマの位置情報を指定します。
「ロケーション・ナビゲータ」内で右クリックし、「Oracle」ノードの下の「ロケーション」から「新規Oracleのロケーション」を選択します。

「EXPENSE_WH_LOCATION」という場所を作成します。接続をテストするためのオプションを選択します。

3. プロジェクト・ナビゲータで、単一のモジュールとスキーマの場所を関連付けます。
「例: フラット・ファイルからのメタデータのインポート」で、メタデータのインポート元の場所に対応するモジュールを作成しました。同様の方法で、ターゲット・スキーマの場所に対応するモジュールを作成する必要があります。

OWB_DEMOプロジェクトでは、「データベース」ノードを開き、「Oracle」ノードを右クリックして「新規Oracleモジュール」を選択します。モジュールを作成するウィザードのプロンプトに従います。モジュールのステータスをWarehouse Targetとして指定することを確認します。

このデモンストレーションでは、モジュールにEXPENSE_WHという名前を付けます。

4. 新規のデータ・ウェアハウスのターゲット・スキーマを習熟します。
プロジェクト・ナビゲータで、新しく定義されたウェアハウス・ターゲット・モジュールのノードを開きます。様々なタイプのオブジェクトがノードの下にリストされます。これらのタイプのオブジェクトは、モジュール内に定義またはインポートできます。

Warehouse Builderのフラット・ファイルのソースについて

ターゲット・モジュールに追加するオブジェクトのタイプは、後で設計するETLロジックに影響を与える場合があります。データ・ソースがフラット・ファイルに由来する場合は、SQL*LoaderコードまたはSQLコードのどちらを生成するか選択できます。コードの各タイプには、固有の利点があります。

Warehouse BuilderでSQL*Loaderを使用するには、「例: フラット・ファイルからのメタデータのインポート」の説明に従ってフラット・ファイルをインポートします。ただし、SQLを使用するには、「演習: ターゲット・モジュールへの外部表の追加」の説明に従ってウェアハウス・モジュールに外部表を定義する必要があります。

演習: ターゲット・モジュールへの外部表の追加

外部表は、フラット・ファイルのデータをリレーショナル形式で表現した表です。この表は、読取り専用の表で、Warehouse Builder内で通常のソース表のように動作します。作成する外部表は、既存のフラット・ファイル内のシングル・レコード・タイプに対応します。

この演習の目的は、前にインポートした2つのフラット・ファイルに必要な外部表を作成することです。2つのファイルの両方にシングル・レコード・タイプがあるので、各ファイルに対して外部表を1つのみ作成する必要があります。

ターゲット・ウェアハウス・モジュールに外部表を追加する手順

1. プロジェクト・ナビゲータで、「データベース」ノード、続いて「Oracle」ノードを開きます。

2. 外部表を作成するターゲット・モジュールを開きます。
EXPENSE_WHモジュールを開きます。

3. 「外部表」ノードを右クリックして「新規外部表」を選択します。
Warehouse Builderで、外部表を作成するウィザードが表示されます。プロンプトに従います。

外部表にEXPENSE_CATEGORIESという名前を付けます。フラット・ファイルを選択するように求められた場合は、EXPENSE_CATEGORIES_CSVを選択します。

4. 前のステップを繰り返し、EXPORT_CSVを表すEXPENSE_DATAと呼ばれる外部表を作成します。

5. 2つの外部表に対して物理ファイル・システムの詳細を構成します。
モジュールから1つの外部表を右クリックし、「構成」を選択します。「データファイル」ノードを右クリックし、「作成」を選択します。デフォルト名NEW_DATAFILE_1をそのまま使用します。外部表がデータを継承するフラット・ファイルの名前を入力します。したがってデータファイル名は、1つの外部表に対してはexpense_categories.csvとし、もう1つの外部表に対してはexport.csvとします。

ディメンションについて

ディメンションは、データを編成する構造です。一般的に使用されるディメンションの例には、顧客、時間および製品があります。

リレーショナル・ディメンションの場合は、ディメンションの使用によって、問合せパフォーマンスが向上します。これは、ユーザーが既知の階層をドリルダウンしてデータを分析することがよくあるためです。階層の例には、年、四半期、月、日という時間階層があります。Oracle Databaseでは、詳細表ではなくマテリアライズド・ビューからデータを取り出す問合せをリライトして、これらの定義済階層を使用します。

一般的なリレーショナル・ディメンション表には、次の特徴があります。

- ウェアハウス・キーと呼ばれる、値が移入された単一列の主キーがあります。
ウェアハウス・キーは、ディメンションを管理し、ディメンション履歴を保持する技術をサポートし、キューブのサイズを削減します。

- ディメンション・オブジェクトとして明示的に定義された1つ以上の階層があります。階層によって、Oracleサーバーで実行されるクエリー・リライトの数が最大化されます。

- ディメンションは、スター・スキーマのデータのプライマリ組織単位です。一般的に使用されるディメンションの例は、カスタマ、「製品」および「時間」です。

ディメンションは、一連のレベルと、これらのレベルに定義されている一連の階層で構成されます。ディメンションを作成する際は、次の内容を定義する必要があります。

- ディメンション属性: ディメンション・メンバーの記述特性。名前とデータ型があります。

- レベル: データの集計のレベルを定義します。たとえば、PRODUCTSディメンションには、合計、グループおよび製品のレベルを設定できます。

- レベル属性: レベル・メンバーの特徴を説明する特性です。ディメンションの各レベルには一連のレベル属性があります。

- 階層: データの編成方法として、順序付けされたレベルまたは一連のデータ値(値ベース階層の場合)を使用する論理構造です。階層構造は一連のレベルの親子関係を説明します。

演習: ディメンションの理解

ディメンションの基本概念および設計を理解するために、事前定義済のディメンションの内容を確認します。

ディメンションの理解を深めるための手順

1. ディメンション・エディタでPRODUCTSディメンションを開きます。
プロジェクト・ナビゲータで、「OWB_DEMO」、「データベース」、「Oracle」、「SALES_WH」にナビゲートして、「ディメンション」を開きます。「PRODUCTS」をダブルクリックします。

Warehouse Builderによってディメンション・エディタが起動されます。ディメンション・エディタは、様々なデータベース・オブジェクトやディメンション・オブジェクトを設計、作成および管理することができる単一インタフェースです。

2. ディメンション属性を監視します。
ディメンション属性は、ディメンション・メンバーの記述特性です。名前とデータ型があります。ディメンション属性には、名前とデータ型があり、ディメンション内の1つ以上のレベルに適用できます。これらは、データを格納するためのレベル属性として実装されます。

ディメンション属性のリストには、ディメンション内のあらゆるレベルに必要なすべての属性が含まれる必要があります。

たとえば、PRODUCTSディメンションには、説明というディメンション属性があります。この属性は、すべてのレベル(合計、グループおよび製品)に適用でき、その中には、これらのレベルの各メンバーに対する説明が格納されます。

3. レベルを監視します。
ディメンションのレベルは、データの集計レベルを表します。値ベース階層が含まれているディメンション以外のディメンションには、少なくとも1つのレベルが含まれている必要があります。各レベルには、レベル属性およびレベル識別子が必要です。

たとえば、PRODUCTSディメンションには、合計、グループおよび製品のレベルを設定できます。

レベルについて

各レベルには、サロゲート識別子とビジネス識別子の2つの識別子が必要です。ディメンションを作成するときは、そのディメンションのサロゲート識別子およびビジネス識別子(複合ビジネス識別子の場合は属性)としてマーク付けされたディメンション属性が、各レベルで実装される必要があります。

サロゲート識別子は、ディメンションのすべてのレベルにまたがって、各レベルのレコードを一意に識別します。この識別子は、単一の属性で構成する必要があります。サロゲート識別子を使用すると、ファクトを最下位ディメンション・レベルのみでなく、どのディメンション・レベルにもフックできます。

リレーショナル実装を使用しているディメンションの場合、サロゲート識別子のデータ型はNUMBERであることが必要です。サロゲート識別子の値は、すべてのディメンション・レベルにまたがって一意である必要があるため、すべてのディメンション・レベルのサロゲート識別子を同じ順序を使用して生成します。

リレーショナル実装の場合、サロゲート識別子は次の目的を果します。

- 子レベルが親レベルとは別の表に格納されている場合、各子レベルのレコードには、親レコードのサロゲート識別子が格納されます。

- ファクト表の各キューブ・レコードには、参照先のディメンション・レコードのサロゲート識別子のみが格納されます。サロゲート識別子を格納することによって、キューブを実装するファクト表のサイズが削減されます。

ビジネス識別子はユーザーが選択する属性リストで構成されます。ビジネス識別子は、特定のレベルで一意であることが必要であり、常にデータ・ソースの自然キーから導出されます。ビジネス識別子はメンバーを一意に識別します。たとえば、製品レベルのビジネス識別子として統一商品コード(UPC)を使用できます。UPCは、各商品に対応する一意のコードです。

ビジネス識別子は、次のように機能します。

- ビジネス期間のレコードを識別します。

- ファクトとディメンション間または2つのレベル間の論理的なリンクを提供します。

- サロゲート・キーを参照可能にします。

ディメンションに子レベルを移入する場合は、その親レベルのビジネス識別子を指定する必要があります。キューブを移入する場合は、そのキューブが参照するディメンション・レベルのビジネス識別子を指定する必要があります。

親識別子は、値ベース階層の親参照に注釈を付けるために使用されます。

たとえば、値ベース階層のEMPLOYEEディメンションに、ID、FIRST_NAME、LAST_NAME、EMAIL、PHONE、JOB_ID、HIRE_DATEおよびMANAGER_IDのディメンション属性があるとします。このディメンションでは、IDがサロゲート識別子で、MANAGER_IDが親識別子です。

レベル属性の定義

レベル属性とはレベル・メンバーを説明する特性です。ディメンションの各レベルには一連のレベル属性があります。レベル属性を定義するには、そのレベルで実装するディメンション属性を選択します。レベル属性には個別名とデータ型があります。データ型は、そのレベル属性に実装されているディメンション属性から継承されます。レベル属性の名前は、実装されているディメンション属性の名前とは異なる名前に変更できます。

すべてのレベルは、一連のディメンション属性のサロゲート識別子およびビジネス識別子としてマークされた属性を実装する必要があります。

階層の定義

ディメンション階層は、データの編成方法として、順序付けされたレベルまたは一連のデータ値(値ベース階層の場合)を使用する論理構造です。階層構造は一連のレベルの親子関係を説明します。レベル・ベース階層には少なくとも1つのレベルが必要です。複数の階層の一部を1つのレベルにできます。

たとえば、TIMEディメンションには次の2つの階層が指定されます。

会計階層: 会計年度 > 会計年度四半期 > 会計年度月 > 会計年度週 > 日

カレンダ階層: カレンダ年 > カレンダ四半期 > カレンダ月 > 日

すべての階層は、完全な1対nの関係になります。親レベルの1つのレコードは子レベルの複数のレコードに対応しますが、子レベルの1つのレコードは階層内で1つの親レコードにのみ対応します。

ディメンション・ロール

ディメンション・ロールとはディメンションの別名です。データ・ウェアハウスでは、キューブが同じディメンションを複数回参照する場合、参照する都度そのディメンションを格納する必要はありません。同じディメンションに対する複数回の参照は混乱の原因となります。混乱を避けるために、ディメンションへの参照ごとに別名を作成すると、結合を瞬時に理解できるようになります。このような場合は、同じディメンションがキューブ内の異なるディメンション・ロールを実行します。

たとえば、売上レコードには次の3つの時間値があります。

- 受注記帳時間

- 受注出荷時間

- 受注履行時間

3つのTIMEディメンションを作成し、それらのディメンションにデータを移入するかわりに、ディメンション・ロールを使用できます。1つのTIMEディメンションのモデルを作成し、そのディメンションに3つのロール(受注記帳時間、受注出荷時間、受注履行時間)を作成します。SALESキューブでは、受注時間、出荷時間および受注履行時間のディメンションを参照できます。

ディメンションがデータベースに格納される場合は、1つのディメンションのみが作成され、このディメンションを各ディメンション・ロールが参照します。ディメンションがOLAPカタログに格納される場合は、Warehouse Builderによって、各ディメンション・ロールに1つのディメンションが作成されます。したがって、TIMEディメンションに3つのロールがある場合、OLAPカタログには3つのディメンションが作成されます。ただし、3つのディメンションはすべて同一の基礎となる表にマッピングされます。これは、OLAPカタログがディメンション・ロールをサポートしていないための対策です。

注意:
ディメンション・ロールは、リレーショナル実装を持つディメンションに対してのみ作成できます。

レベルの関係

レベルの関係とは、ディメンション階層内のレベル間のアソシエーションです。レベルの関係は、階層内の親レベルへの参照を格納するレベル属性を使用して実装されます。

たとえば、PRODUCTSディメンションに「合計 > グループ > 製品」という階層があるとします。Warehouse Builderでは、2つのレベルの関係(製品からグループ、グループから合計)が作成されます。2つの新しい属性には、このレベルの関係(製品レベルでの関係とグループ・レベルでの関係)が実装されます。これらの属性には、親レベルのサロゲートIDが格納されます。

ディメンションの例

ディメンションの一例として、製品データの編成に使用するPRODUCTSディメンションを紹介します。表4-1に、PRODUCTSディメンションの各レベルと、ディメンション内の各レベルのサロゲート識別子とビジネス識別子をリストします。

表4-1 PRODUCTSディメンションのレベルの詳細

レベル

属性名

識別子

合計

ID

サロゲート

名前

ビジネス

説明

グループ

ID

サロゲート

名前

ビジネス

説明

製品

ID

サロゲート

UPC

ビジネス

名前

説明

パッケージ・タイプ

パッケージ・サイズ

PRODUCTSディメンションの階層は、次のとおりです。

階層1: 合計 > グループ > 製品

制御行

Warehouse Builderにより、ファクト・データを各レベルのディメンションにリンクできる制御行が作成されます。たとえば、TIMEディメンションを2つの異なるキューブで再利用して、予算データを月レベルで記録し、実際のデータを日レベルで記録する場合などです。ディメンションは制御行と一緒にロードされるため、追加定義をすることなくこのアクションを実行できます。ディメンション階層の各メンバーは、単一のレコードを使用して表示されます。

すべての制御行には-2から始まる負のディメンション・キー値があります。上位レベルのレベル値では行が生成され、ファクト表に対して一意でリンクする行として動作できます。このリンクの下位レベルまたは制御行は無効化されます。

「ディメンションの例」で説明されているPRODUCTSディメンションを検討します。4つの製品カテゴリを含む表からデータをこのディメンションにロードします。Warehouse Builderは表4-2に示されるディメンションに制御行を挿入します。これらの行によりどのディメンション・レベルでもキューブにリンクできます。表にはすべてのディメンション属性値が含まれるわけではありません。

表4-2 PRODUCTSディメンションに作成された制御行

ディメンション・キー

合計名

グループ名

製品名

-3

TOTAL

-9

TOTAL

ハードウェア

-10

TOTAL

ソフトウェア

-11

TOTAL

エレクトロニクス

-12

TOTAL

周辺機器

ディメンションの実際の行数を取得するには、NULL行を除外するWHERE句を含めることで行数を数えます。たとえば、PRODUCTSでの数を取得するには、PRODUCTS内のNULL行を除外するWHERE句を含めて行数を数えます。

ディメンションの実装

ディメンションの実装とは、ディメンションおよびそのデータを物理的に格納する方法を指定することです。Warehouse Builderによって、ディメンション・オブジェクトに対して複数のタイプの実装(多次元実装を含む)を行うことができます。ただし、このガイドでは、リレーショナル実装についてのみ説明します。

スター・スキーマ

スター・スキーマ実装では、Warehouse Builderによって単一の表にディメンション・データが格納されます。同じ表またはビューに複数のディメンション・レベルのデータが格納されるため、表にディメンション・キーの列を指定する必要があります。ディメンション・キーの列は、ディメンションの主キーです。この列はキューブの外部キー参照も形成します。

各レベルには、ディメンション属性のサブセットが実装されます。デフォルトでは、レベル属性の名前はディメンション属性の名前と同じです。すべてのレベルのデータが同じ表に格納されることで生じる名前の衝突を回避するため、Warehouse Builderでは、スター表の名前の指定に、次のガイドラインが使用されます。

- レベル属性の名前が一意でない場合は、Warehouse Builderによってレベル名に接頭辞が付けられます。

- レベル属性の名前が一意の場合は、接頭辞は使用されません。

注意:
接頭辞が使用されないようにするには、「ディメンションの作成」ウィザードまたはデータ・オブジェクト・エディタで、レベル属性の名前を明示的に変更する必要があります。

たとえば、スター・スキーマを使用してPRODUCTSディメンションを実装する場合、Warehouse Builderは単一の表を使用し、ディメンションにすべてのレベルを実装します。

図4-1 PRODUCTSディメンションのスター・スキーマ実装

「図4-1 PRODUCTSディメンションのスター・スキーマ実装」の説明

バインド

バインドを実行する場合は、各属性のデータおよびディメンション内のレベルの関係を格納するデータベース列を指定します。ディメンションに対して自動バインドまたは手動バインドを実行できます。

自動バインド: 自動バインドを実行すると、Warehouse Builderによって、ディメンション・オブジェクトの属性がそのデータを格納するデータベース列にバインドされます。自動バインドを初めて実行するときは、ディメンション・データの格納に使用される表も作成されます。

すでにバインド済のディメンションに対して自動バインドを実行すると、Warehouse Builderでは次のルールが使用されます。

- ディメンションの実装方法が同じ場合は、Warehouse Builderによって既存の実装オブジェクトにディメンション・オブジェクトが再バインドされます。
たとえば、スター・スキーマ実装方法を使用してPRODUCTSディメンションを作成し、自動バインドを実行したとします。ディメンション・データはPRODUCTSと呼ばれる表に格納されます。後日、ディメンション定義を変更しましたが、実装方法はスター・スキーマのままです。この状況でPRODUCTSディメンションを自動バインドすると、Warehouse Builderによって同じ実装表にPRODUCTSディメンションの属性が再バインドされます。

- ディメンションの実装方法を変更すると、Warehouse Builderによって、古い実装オブジェクトが削除され、一連の新しい実装表が作成されます。古い実装オブジェクトを保持する場合は、自動バインドを実行する前に、ディメンション・オブジェクトをアンバインドする必要があります。実装方法の詳細は、「スター・スキーマ」を参照してください。
たとえば、スター・スキーマ実装方法を使用してPRODUCTSディメンションを作成し、それを実装表にバインドしたとします。その後、このディメンションを編集し、実装方法をスノーフレーク・スキーマに変更しました。変更したPRODUCTSディメンションの自動バインドを実行すると、Warehouse Builderによって、ディメンション・データが格納されていた表は削除され、新しい実装表が作成されて、ディメンション属性および関係が新しい実装表にバインドされます。

自動バインドを実行する手順

1. プロジェクト・ナビゲータで、ディメンションを選択します。

2. 「ファイル」メニューから「バインド」を選択します。
「バインド」オプションが有効になっていない場合は、ディメンションがリレーショナル・ディメンションであるかどうか、また「手動」オプションが「記憶域」タブの「実装」セクションで設定されていないかどうかをチェックします。

「スター・スキーマ」に説明されているように、自動バインドによって実装設定が使用されます。

手動バインド: 通常は、手動バインドを使用して既存の表をディメンションにバインドします。自動バインドまたは再バインドが不要な場合は、手動バインドを使用します。

ディメンションの手動バインドを実行する手順

1. ディメンション・データの格納に使用する実装オブジェクト(表またはビュー)を作成します。
リレーショナル・ディメンションの場合は、ディメンションのサロゲート識別子のロードに使用する順序を作成します。既存の順序を使用することもできます。

2. プロジェクト・ナビゲータで、ディメンションを右クリックして「開く」を選択します。
ディメンション・エディタが開きます。

3. 「物理的バインド」タブに移動します。

4. コンポーネント・パレットから、実装オブジェクトを表す演算子をキャンバスにドラッグ・アンド・ドロップします。
「新規または既存のオブジェクトを追加」ダイアログ・ボックスが表示されます。たとえば、ディメンション・データが表に格納されている場合は、コンポーネント・パレットからキャンバスに「表演算子」をドラッグ・アンド・ドロップします。「新規または既存の表を追加」ダイアログ・ボックスが表示されます。

5. 「既存のオブジェクトを選択」オプションを選択し、選択ツリーに表示されるオブジェクトのリストからデータ・オブジェクトを選択します。

6. 「OK」をクリックします。
追加したオブジェクトを表すノードがキャンバスに表示されます。

7. ディメンション・データの格納に複数のデータ・オブジェクトが使用される場合は、各データ・オブジェクトについてステップ4から6を実行します。

8. ディメンションの各レベルの属性を、そのデータを格納する列にマッピングします。ディメンション属性の上でマウスを押したまま、属性値を格納する列にドラッグ・アンド・ドロップします。
レベルの関係も、そのデータを格納するデータベース列にマッピングします。

たとえば、「ディメンションの例」に記載されているPRODUCTSディメンションの場合、PRODUCTSディメンションのグループ・レベルの名前属性は、Products_tab表のGroup_name属性に格納されます。名前属性の上でマウスを押したまま、Products_tab表のGroup_name属性にドラッグ・アンド・ドロップします。

キューブについて

キューブには、メジャーおよび1つ以上のディメンションへのリンクが含まれます。キューブの軸にはディメンション・メンバーが組み込まれ、キューブの本体にはメジャーの値が格納されます。ほとんどのメジャーは加法的なメジャーです。たとえば、売上データは、キューブ・エッジに時間、製品および顧客のディメンション値が指定され、キューブ本体にバリュー売上とドル売上のメジャーから値が格納されるキューブに編成できます。

キューブは、外部キー制約によってディメンション表にリンクされます。これらの制約は、データ整合性が最も重要とされるデータ・ウェアハウス環境には不可欠です。この制約によって、データ・ウェアハウスを使用する日常業務での参照整合性が順守されます。

データ分析アプリケーションでは、通常、多くのディメンションにわたってデータが集計されます。これによって、データの変則的または特異なパターンを確認できます。キューブの使用は、この種の操作を実行する最も効率的な方法です。リレーショナル実装で、ウェアハウス・キーが設定されているディメンションを設計する場合、キューブの行の長さは一般的に短くなります。これは、ウェアハウス・キーの長さが対応する本来のデータより短いためです。その結果、キューブ・データに必要な記憶領域は少なくなります。

一般的なキューブには、次の要素が含まれます。

- 一連の外部キー参照列、またはデータ・リストの場合は人工キーまたは一連のウェアハウス・キー列に定義された主キー。キューブがデータ・リストの場合、外部キー参照列ではキューブの各行は一意に識別されません。

- 表を対応するディメンションにリンクする一連の外部キー参照列。

キューブの定義

キューブは、一連のディメンションにわたって定義されたメジャーの集合で構成されます。キューブを作成するには、次の要素を定義する必要があります。

- キューブ・メジャー

- キューブのディメンション

キューブ・メジャー

メジャーとは、調査および分析可能なデータで、通常は加法的な数値になります。メジャーの例としては、売上、原価および収益があります。キューブには、1つ以上のディメンションが必要です。メジャーの集計も可能です。ただし、集計できるのは数値メジャーのみです。

キューブのディメンション

キューブは一連のディメンションで定義されます。キューブはディメンション内で最下位レベル以外のレベルを参照できます。

純粋なリレーショナル実装を使用するキューブでは、ディメンション・ロールによって、複数回同じディメンションを再使用できます。ディメンション・ロールの詳細は、「ディメンション・ロール」を参照してください。

キューブを有効にする前に、キューブが参照するディメンションすべてが有効になっていることを確認してください。

ディメンション参照を定義する場合に指定する要素

- キューブが参照するディメンションとディメンション内のレベル。
リレーショナル実装を使用するキューブでは、ディメンションの中間レベルを参照できます。Warehouse Builderでは、レベルの非サロゲート識別子(ビジネス・キーなど)への参照をサポートしています。

- リレーショナル実装を使用するディメンションの場合は、キューブ内でディメンション参照が実行するロールを示す、各ディメンションのディメンション・ロール。ディメンション・ロールの指定はオプションです。

キューブの例

Salesキューブには、集計された売上データが格納されます。このキューブにはValue_salesおよび Dollar_salesという2つのメジャーが含まれています。

- Value_sales: 売上額を売上数量に換算して格納します。

- Dollar_sales: 売上額を格納します。

表4-3に、Salesキューブのディメンションを示します。この表には、キューブが参照するディメンションの名前とディメンションのレベルがリストされています。

表4-3 SALESキューブのディメンション

ディメンション名

レベル名

Products

製品

Customers

顧客

Times

日

キューブの実装

キューブを実装する際は、キューブの物理的な記憶域の詳細を指定します。ディメンションの場合と同様に、Warehouse Builderによって、リレーショナル形式または多次元形式でキューブを実装できます。このガイドでは、リレーショナル実装について説明します。

キューブのリレーショナル実装

キューブ・データの格納に使用するデータベース・オブジェクトは、ファクト表と呼ばれます。キューブは1つのファクト表のみを使用して実装する必要があります。ファクト表にはキューブのメジャーおよびディメンション参照の列が含まれます。

キューブを実装する手順

- キューブ・データを格納する表またはマテリアライズド・ビューを選択します。

- 各メジャーについて、メジャー・データを格納する列を選択します。

- 各ディメンション参照について、ディメンション参照を格納する列を選択します。
各ディメンション参照は、ファクト表の列およびファクト表からディメンション表への外部キー(オプション)に対応します。ファクト表からディメンション表への1対nの関係が順守される必要があります。

図4-2 SALESキューブの実装

「図4-2 SALESキューブの実装」の説明

バインド

バインドを実行する場合は、キューブのメジャーとディメンション参照の各データを格納するデータベース列を指定します。キューブに対して自動バインドまたは手動バインドを実行できます。

自動バインド: 自動バインドを実行すると、Warehouse Builderによって、キューブ・データを格納する表が作成され、キューブのメジャーおよび参照がデータベースの列にバインドされます。自動バインドを実行する手順の詳細は、「自動バインド」を参照してください。

キューブの自動バインドを実行する場合は、キューブが参照するディメンションを自動バインドした後に、キューブを自動バインドします。キューブが最後に自動バインドされた後に、そのキューブによって参照されるディメンションが自動バインドされた場合は、キューブを配布できません。

たとえば、TIMESディメンションとPRODUCTSディメンションを参照するSALESキューブを作成し、そのキューブの自動バインドを実行したとします。その後、PRODUCTSディメンションの定義を変更しました。ここで、再度SALESキューブを自動バインドしようとすると、Warehouse Builderによってエラーが生成されます。最初にPRODUCTSディメンションを自動バインドした後に、キューブを自動バインドする必要があります。

手動バインド: 手動バインドでは、最初にキューブ・データを格納する表またはビューを作成し、次にそのデータを格納するデータベースの列にキューブの参照およびメジャーをマッピングする必要があります。あるいは、既存のデータベース表またはビューを使用して、キューブ・データを格納することもできます。

キューブの手動バインドを実行する手順

1. キューブ・データを格納する表またはビューを作成します。

2. プロジェクト・ナビゲータで、キューブを右クリックして「開く」を選択します。
キューブ・エディタが開きます。

3. 「物理的バインド」タブに移動します。

4. コンポーネント・パレットから、実装オブジェクトを表す演算子をキャンバスにドラッグ・アンド・ドロップします。
「新規または既存のオブジェクトを追加」ダイアログ・ボックスが表示されます。たとえば、キューブ・データが表に格納されている場合は、コンポーネント・パレットからキャンバスに「表演算子」をドラッグ・アンド・ドロップします。「新規または既存の表を追加」ダイアログ・ボックスが表示されます。

5. 「既存のオブジェクトを選択」を選択し、選択ツリーに表示されるオブジェクトのリストからデータ・オブジェクトを選択します。

6. 「OK」をクリックします。
追加したオブジェクトを表すノードがキャンバスに表示されます。

7. キューブのメジャーとディメンション参照をキューブ・データが格納される列にマッピングします。メジャーまたはディメンション参照をマウス・ボタンで押したまま、そのメジャーまたはディメンション参照を格納するデータ・オブジェクト属性にドラッグ・アンド・ドロップします。

第II部

データ・ウェアハウスへのデータのロード

第II部では、データ・ウェアハウスへのデータのロード方法について説明します。内容は次のとおりです。

- 第5章「ETLロジックの定義」

- 第6章「ターゲット・スキーマへの配布およびETLロジックの実行」

5 ETLロジックの定義

Oracle Warehouse Builderでデータ・オブジェクトの定義を作成およびインポートした後は、データをソースからターゲットに移動する抽出、変換およびロード(ETL)の各操作を設計できます。Warehouse Builderでは、マッピングを使用してこれらの操作を設計します。

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

- マッピングおよび演算子について

- マッピングを定義する手順の要約

- マッピングの作成

- 演算子の追加

- 演算子の編集

- 演算子、グループおよび属性の接続

- 演算子、グループおよび属性プロパティの設定

- 演算子とワークスペース・オブジェクトの同期化

マッピングおよび演算子について

マッピングとはデータをソースから抽出し、変換してターゲットにロードする一連の操作を表します。これによりデータ・フローおよびデータで実行される操作がビジュアル表示されます。マッピングをWarehouse Builderで設計する場合は、マッピング・エディタ・インタフェースを使用します。

マッピングの基本となる設計要素は演算子です。演算子を使用して、データ・フローでソースおよびターゲットを表現します。また、演算子を使用して、ソースからターゲットへのデータの変換方法を定義することもできます。ソースとして選択する演算子は、マッピングの設計方法に影響を与えます。Warehouse Builderでは、選択された演算子に基づいて、次のいずれかのマッピング生成言語にマッピングが割り当てられます。

- PL/SQL

- SQL*Loader

- ABAP

各コード言語では、マッピングを設計する際、特定のルールに従う必要があります。

このガイドでは、PL/SQLマッピングを定義する方法を説明します。他のタイプのマッピングを定義するには、『Oracle Warehouse Builderデータ・モデリング、ETLおよびデータ・クオリティ・ガイド』を参照してください。PL/SQLマッピングを定義する基本ルールは、PL/SQLマッピングには、フラット・ファイル演算子またはSAP/R3ソース以外のすべてのタイプのソース演算子を含めることができることです。

マッピングを定義する手順の要約

マッピングを定義する場合に参照する項

1. マッピングの作成

2. 演算子の追加

3. 演算子の編集

4. 演算子、グループおよび属性の接続

5. 演算子、グループおよび属性プロパティの設定

6. Warehouse Builderのオンライン・ヘルプのマッピング構成のリファレンス

7. マッピング・デザインに問題がない場合、ツールバーの「生成」アイコンを選択してコードを生成します。

後続の手順

マッピングを設計してマッピングのコードを生成した後、プロセス・フローを作成するか、直接配布を続行して実行できます。

プロセス・フローを使用して、マッピングを相互に関連付けます。たとえば、あるマッピングが完了すると電子メール通知がトリガーされて別のマッピングが起動するように、プロセス・フローを設計できます。

マッピングおよび作成した関連するプロセス・フローを配布し、マッピングを実行します。

マッピングの作成

マッピングを作成する手順

1. プロジェクト・ナビゲータの「マッピング」ノードに移動します。このノードは、ウェアハウス・ターゲット・モジュールの下、「データベース」フォルダの下の「Oracle」フォルダにあります。

図5-1 プロジェクト・ナビゲータの「マッピング」ノード

「図5-1 プロジェクト・ナビゲータの「マッピング」ノード」の説明

2. 「マッピング」を右クリックして「新規マッピング」を選択します。
「マッピングの作成」ダイアログ・ボックスが表示されます。

3. 新しいマッピングの名前と説明(オプション)を入力します。
マッピング名の指定と説明の記述に関するルールを表示するには、「ヘルプ」を選択します。

4. 「OK」をクリックします。
マッピングの定義が保存され、その名前がプロジェクト・ナビゲータ内に挿入されます。また、そのマッピングのマッピング・エディタが表示され、タイトル・バーにマッピングの名前が表示されます。

以前に作成したマッピングを開く手順

1. プロジェクト・ナビゲータで、ウェアハウス・ターゲット・モジュールを「データベース」フォルダに移動して、次にOracle Databaseのフォルダに移動します。

2. 「マッピング」ノードを開きます。

3. 次のいずれかの方法で、マッピング・エディタを開きます。

- マッピングをダブルクリックします。

- マッピングを選択し、「ファイル」メニューから「開く」を選択します。

- マッピングを選択し、[Ctrl]キーを押しながら[O]キーを押します。

- マッピングを右クリックし、「開く」を選択します。

Warehouse Builderによって、マッピング・エディタが表示されます。

演算子のタイプ

マッピングを設計するときは、マッピング・エディタ・パレットから演算子を選択し、キャンバスにドラッグできます。

- Oracleソースとターゲット演算子: これらの演算子を使用して、Oracle表、ビュー、マテリアライズド・ビューなどのOracle Databaseオブジェクトを示します。

- リモートおよびOracle以外のソース演算子とターゲット演算子: これらの演算子の使用には、特別な要件があります。

- データ・フロー演算子: データ・フロー演算子を使用して、データを変換します。

- 事前/事後処理演算子: マッピングの実行前または後に処理を実行するには、事前/事後処理演算子を使用します。マッピングに対する値を指定するには、マッピング・パラメータ演算子を使用します。

- プラガブル・マッピング演算子: プラガブル・マッピング演算子は、マッピング演算子の再利用可能なグループで、単一の演算子として機能します。

演算子の追加

演算子をマッピングに追加する手順は、選択する演算子のタイプによって異なります。これは、一部の演算子はワークスペース・オブジェクトにバインドされ、その他の演算子はバインドされないためです。一般的に、データ・ソースまたはターゲット演算子を追加すると、Warehouse Builderによって、Warehouse Builderワークスペースのそのオブジェクトのバージョンと、マッピング・エディタ用の個別のバージョンが維持されます。たとえば、表演算子をマッピングに追加した場合は、Warehouse Builderによってその表のコピーがワークスペースで維持されます。個々のバージョンは、1つにバインドされます。つまり、マッピングのバージョンがワークスペースのバージョンに バインド されます。

2つのバージョンを区別するために、この項では、ワークスペース内のオブジェクトを総称的にワークスペース・オブジェクトと呼び、具体的には、ワークスペース表、ワークスペース・ビューのように表現します。また、マッピングの演算子は表演算子、ビュー演算子のように表現します。したがって、ディメンションをマッピングに追加する場合、マッピングのディメンションはディメンション演算子、ワークスペースのディメンションはワークスペース・ディメンションと表されます。

Warehouse Builderでは、ユーザーがこれらのオブジェクトでの定義の変更を同期化できるように、一部の演算子に個別のワークスペース・オブジェクトが保持されます。たとえば、ワークスペース表の新規メタデータ定義を再インポートした場合は、これらの変更内容をマッピングの表演算子に伝播する必要があります。反対に、マッピングの表演算子を変更した場合は、これらの変更内容を関連するワークスペース表に伝播する必要があります。これらのタスクは、同期化と呼ばれるプロセスによって実現します。Warehouse Builderでは、同期化が自動的に行われます。かわりに、マッピング・エディタから手動で同期化することもできます。

演算子をマッピングに追加する手順

1. マッピング・エディタを開きます。

2. 「グラフ」メニューから「追加」を選択し、演算子を選択します。または、コンポーネント・パレットからマッピング・エディタのキャンバスに演算子のアイコンをドラッグ・アンド・ドロップします。
ワークスペース・オブジェクトにバインドできる演算子を選択すると、マッピング・エディタに「マッピングoperator_nameの追加」ダイアログ・ボックスが表示されます。このダイアログ・ボックスの使用方法については、「ヘルプ」をクリックしてください。

ワークスペース・オブジェクトにバインドできない演算子を選択した場合は、演算子を作成するためのウィザードまたはダイアログ・ボックスが表示されます。

3. Warehouse Builderに表示される指示に従い、「OK」をクリックします。
マッピング・エディタでは、キャンバスに最大化された演算子が表示されます。左上の隅に演算子名が表示されます。各属性名およびデータ型を表示できます。

演算子を最小化するには、右上隅の矢印をクリックします。マッピング・エディタのキャンバスに演算子がアイコンとして表示されます。

図5-2 マッピング・エディタに表示された表演算子のソース

「図5-2 マッピング・エディタに表示された表演算子のソース」の説明

ワークスペース・オブジェクトにバインドする演算子の追加

ワークスペース・オブジェクトにバインドできる演算子を追加すると、マッピング・エディタに「マッピングoperator_nameの追加」ダイアログ・ボックスが表示されます。次のオプションから1つ選択します。

- バインドされていない演算子を属性なしで作成

- 既存のワークスペース・オブジェクトから選択してバインド

バインドされていない演算子を属性なしで作成

このオプションは、マッピング・エディタを使用して、新規ステージング領域表や新規ターゲット表など、新しいワークスペース・オブジェクトを定義する場合に使用します。

「バインドされていない演算子を属性なしで作成」を選択した後、新しいオブジェクトの名前を入力します。演算子が属性なしでキャンバスに表示されます。

これで、演算子の属性を追加および定義できるようになりました(「演算子の編集」を参照)。次に、ターゲット・モジュールに新規ワークスペース・オブジェクトを作成するために、演算子を右クリックして「作成とバインド」を選択します。

このオプションをマッピング設計で使用する方法の例は、「例: マッピング・エディタによるステージング領域表の作成」を参照してください。

既存のワークスペース・オブジェクトから選択してバインド

このオプションは、ワークスペース内の定義済またはインポート済のオブジェクトに基づいて、演算子を追加する場合に使用します。

接頭辞を入力してオブジェクトを検索するか、選択したモジュール内のオブジェクトの表示リストからオブジェクトを選択します。

複数のアイテムを選択するには、[Ctrl]キーを押しながら各アイテムをクリックします。連続したアイテムのグループを選択するには、選択範囲の最初のオブジェクトをクリックし、[Shift]キーを押しながら最後のオブジェクトをクリックします。

演算子は、マッピングと同じモジュール内のワークスペース・オブジェクトまたは別のモジュールのワークスペース・オブジェクトに基づいて追加できます。別のモジュールのワークスペース・オブジェクトを選択すると、マッピング・エディタによってコネクタが作成されます(コネクタが存在していない場合)。このコネクタによって、マッピングのロケーションとワークスペース・オブジェクトのロケーション間のデータの移動パスが確立されます。

演算子の編集

各演算子には、エディタが関連付けられています。その演算子エディタを使用して、演算子、グループおよび属性に関する一般的な情報と構造的な情報を指定します。演算子エディタでは、グループおよび属性を追加または削除したり、名前を変更できます。演算子の名前も変更できます。

演算子の編集は、ロード・プロパティや条件付き動作の割当てとは異なります。ロード・プロパティや条件付き動作を指定するには、プロパティ・ウィンドウ(「演算子、グループおよび属性プロパティの設定」を参照)を使用します。

演算子、グループまたは属性を編集する手順

1. マッピング・エディタのキャンバスから演算子を選択するか、演算子内のグループまたは属性を選択します。

2. 選択したアイテムを右クリックし、「詳細をオープン」を選択します。
マッピング・エディタに演算子エディタが表示され、「名前」タブ、「グループ」タブ、および各タイプの演算子のグループの「入力/出力」タブが表示されます。

いくつかの演算子には追加のタブが含まれます。たとえば、Match Merge演算子には一致ルールおよびマージ・ルールを定義するタブが含まれます。

3. 各タブに表示されるプロンプトに従い、「OK」をクリックして終了します。
タブの実行方法については、「ヘルプ」を参照してください。

演算子、グループおよび属性の接続

マッピング・ソース演算子、データを変換する演算子およびターゲット演算子を選択した後は、これらの演算子を接続できます。データ・フローの接続により、ソースから演算子を通過してターゲットに至るデータ・フローの様子が視覚的に表されます。

演算子は、次のいずれかの方法で接続できます。

- 演算子の接続: 2つの演算子間でグループを接続するための条件を定義します。

- グループの接続: 2つのグループ間ですべての属性を接続するための条件を定義します。

- 属性の接続: 一度に個々の演算子属性を相互に接続します。

- 演算子ウィザードの使用: ピボット演算子、Name and Address演算子などの演算子は、ウィザードを使用してデータ・フロー接続を定義できます。

演算子の接続

ある演算子と別の演算子との間に既存の接続がない場合は、その演算子同士を接続できます。接続する2つの演算子は、アイコン形式で表示されている必要があります。また、グループから演算子に接続することもできます。グループの上でマウスの左ボタンを押したまま、演算子のタイトル上にドラッグ・アンド・ドロップしてください。

演算子を別の演算子に接続する手順

1. 接続元の演算子を選択します。

2. マウス・ポインタを演算子のアイコン上に置き、左ボタンをクリックしたままにします。

3. その演算子から、接続先の演算子のアイコンにマウスをドラッグします。

4. ターゲットの演算子の上でマウス・ボタンを放します。
「マッピング接続」ダイアログ・ボックスが表示されます。

5. 「接続する属性グループ」セクションで、次の値を選択します。
ソース・グループ: ターゲット演算子に接続する必要があるグループをソース演算子から選択します。

ターゲット・グループ: ソース・グループにマップする必要があるグループをターゲット演算子から選択します。

6. 「接続オプション」セクションで、ソース属性とターゲット属性の接続に使用する方法を選択し、「プレビュー」をクリックします。

7. 「OK」をクリックして、「マッピング接続」ダイアログボックスを閉じます。

グループの接続

グループを接続すると、属性が自動的にコピーされるか、「マッピング接続」ダイアログ・ボックスが表示されます。

グループを別のグループに接続する手順

1. 接続元のグループを選択します。

2. マウス・ポインタをグループの上に置き、左ボタンをクリックしたままにします。

3. そのグループから、接続先のグループにマウスをドラッグします。

4. ターゲットのグループの上でマウス・ボタンを放します。
演算子グループを接続する先のターゲット・グループに属性が含まれる場合は、「マッピング接続」ダイアログ・ボックスが表示されます。

5. 「接続オプション」セクションで、ソース属性とターゲット属性の接続に使用する方法を選択し、「プレビュー」をクリックします。

6. 「OK」をクリックして、「マッピング接続」ダイアログボックスを閉じます。

演算子グループを既存の属性を持たないターゲット・グループに接続すると、属性が自動的にコピーされ、各属性が接続されます。これは、「例: マッピング・エディタによるステージング領域表の作成」に示すようなマッピングを設計する場合に便利です。

例: マッピング・エディタによるステージング領域表の作成

マッピング・エディタでバインドされていない表演算子を使用すると、ステージング領域表をすばやく作成できます。

次の手順は、既存のソース表に基づいてステージング表を作成する方法を示しています。この手順は、ビュー、マテリアライズド・ビュー、フラット・ファイルおよび変換の作成にも使用できます。

ソース表をステージング表にマップする手順

1. マッピング・エディタで、ソース表を追加します。
メニュー・バーから「マッピング」、「追加」、「データ・ソース/ターゲット」の順に選択します。「データ・ソース/ターゲット」メニューで、「表演算子」を選択します。

2. 「表演算子の追加」ダイアログ・ボックスを使用して、マッピング内のソース表の演算子を選択およびバインドします。「表演算子の追加」ダイアログ・ボックスから、「バインドされていない演算子を属性なしで作成」を選択します。

図5-3 バインドされていないステージング表(属性なし)とソース表

「図5-3 バインドされていないステージング表(属性なし)とソース表」の説明

3. ソース演算子のグループにマウス・ポインタを置き、マウス・ボタンを押したままにします。

4. ステージング領域表グループまでマウスをドラッグします。
Warehouse Builderによって、ソース属性がステージング領域表にコピーされ、2つの演算子が接続されます。

5. マッピング・エディタでは、マッピングに追加したバインドされていない表を選択します。右クリックして「作成とバインド」を選択します。

図5-4 「作成とバインド」ダイアログ・ボックス

「図5-4 「作成とバインド」ダイアログ・ボックス」の説明

6. 「作成場所」に、表を作成するターゲット・モジュールを指定します。
Warehouse Builderによって、指定したターゲット・モジュールに新しい表が作成されます。

属性の接続

一方の演算子の単一の出力属性から、他方の演算子の単一の入力属性に線を引きます。

属性を接続する手順

1. マウス・ボタンをクリックしたまま、ポインタを出力属性の上に置きます。

2. 出力属性からデータのフロー先となる入力属性にマウスをドラッグします。
マウスをドラッグするとき、接続を示す行がマッピング・エディタ・キャンバスに表示されます。

3. 入力属性の上でマウス・ボタンを放します。

4. ステップ1から3を繰り返し、必要なデータ・フロー接続をすべて作成します。

図5-5 マッピングで接続した演算子

「図5-5 マッピングで接続した演算子」の説明

属性を接続するときは、次のルールに留意します。

- 同じ入力属性には2度接続できません。

- 同じ演算子内の属性には接続できません。

- 入力専用の属性から接続することも、出力専用の属性に接続することもできません。

- 確立されているカーディナリティに矛盾する方法では演算子を接続できません。かわりに、ジョイナ演算子を使用します。

演算子、グループおよび属性プロパティの設定

キャンバスでオブジェクトを選択すると、エディタの左側にあるプロパティ・インスペクタに、関連するプロパティが表示されます。

図5-6 表演算子のプロパティ・インスペクタ

「図5-6 表演算子のプロパティ・インスペクタ」の説明

次のタイプのプロパティを表示および設定できます。

- 演算子のプロパティ: 演算子全体に影響を与えるプロパティです。設定できるプロパティは演算子のタイプに依存します。

- グループのプロパティ: これは属性のグループに影響を与えるプロパティです。ほとんどの演算子には、グループのプロパティが設定されていません。グループ・プロパティが設定される演算子の例としては、スプリッタ演算子やデュプリケータ解除演算子があります。

- 属性のプロパティ: これはソース演算子とターゲット演算子の属性に関するプロパティです。属性のプロパティの例としては、データ型、精度、スケールがあります。

演算子とワークスペース・オブジェクトの同期化

マッピングに使用する多くの演算子に対応する定義は、Warehouse Builderワークスペースにあります。このことは、表演算子やビュー演算子など、ソース演算子とターゲット演算子に当てはまります。また、順序演算子や変換演算子など、定義が複数のマッピングにまたがって使用される他の演算子にも当てはまります。このような演算子を変更するときは、変更内容をワークスペース・オブジェクトに伝播する必要があります。

変更の伝播方向は、次の選択肢から決定できます。

ワークスペース・オブジェクトから演算子への同期化: 本番環境でマッピングの使用を開始した後、ソースまたはターゲットに対してETL設計に影響する変更が行われる場合があります。通常、このような変更を管理する最善の方法は、Warehouse Builderのオンライン・ヘルプで説明されているように、Warehouse Builderの依存性マネージャを使用することです。依存性マネージャを使用すると、変更による影響が自動的に評価され、影響を受けるすべてのマッピングがまとめて同期化されます。また、「ワークスペース・オブジェクトから演算子への同期化」で説明されているように、マッピング・エディタで、オブジェクトを手動で同期化することもできます。

演算子からワークスペース・オブジェクトへの同期化: マッピングの演算子を変更する場合は、変更内容を対応するワークスペース定義に伝播させます。たとえば、インポートしてマッピングに使用したソースの場合、属性に複合物理名が付いている場合があります。

同期化がリフレッシュとは異なることに注意してください。リフレッシュ・コマンドでは、マルチユーザー環境で他のユーザーが行った変更にあわせて、確実に最新の状態が保たれます。同期化では、対応するワークスペース・オブジェクトと演算子が照合されます。

演算子の同期化

同期化する場合は、演算子を1つ選択し、指定したワークスペース・オブジェクトの定義とその演算子を同期化します。

演算子を同期化する手順

1. マッピング・エディタのキャンバスで演算子を選択します。

2. 「編集」メニューから、「同期化」を選択するか、演算子のヘッダーを右クリックして「同期化」を選択します。

図5-7 演算子の同期化

「図5-7 演算子の同期化」の説明

3. デフォルトでは、Warehouse Builderにより、選択した演算子とワークスペース内の関連するオブジェクトを同期化するためのオプションが選択されます。デフォルトを受け入れるか、リスト・ボックスから別のワークスペース・オブジェクトを選択します。
この手順では、ワークスペース・オブジェクトから演算子への同期化、または演算子からワークスペース・オブジェクトへの同期化のいずれかも選択します。

4. (オプション)「拡張」をクリックして「一致方針」を設定します。
「一致方針」の使用方法を参照するには、「ヘルプ」を選択します。

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

ワークスペース・オブジェクトから演算子への同期化

マッピング・エディタでは、次のような理由により、ワークスペース・オブジェクトから演算子への同期化を実行できます。

- 手動による変更の伝播: ワークスペース・オブジェクトの変更を関連する演算子に伝播します。ワークスペース・オブジェクトの変更には、構造的な変更、属性名の変更、属性のデータ型の変更などがあります。ワークスペース・オブジェクトの変更を複数のマッピングに自動的に伝播する方法は、Warehouse Builderのオンライン・ヘルプを参照してください。

- 演算子と新規ワークスペース・オブジェクトの同期化: たとえば、あるバージョンのデータ・ウェアハウスから後のバージョンのデータ・ウェアハウスにマッピングを移行し、バージョンごとに異なるオブジェクト定義を維持する場合は、演算子と新規のワークスペース・オブジェクトを関連付けることができます。

図5-8 異なるワークスペース・オブジェクトからの同期化

「図5-8 異なるワークスペース・オブジェクトからの同期化」の説明

- 表によるマッピングのプロトタイプ作成: 設計環境で作業している場合は、表を使用したETLロジックの設計を選択できます。ただし、本番環境では、他のワークスペース・オブジェクト・タイプ(ビュー、マテリアライズド・ビュー、キューブなど)に基づいたマッピングが可能です。

ワークスペース・オブジェクトに基づく演算子の同期化

表5-1に、演算子および同期化できるワークスペース・オブジェクトのタイプを示します。

表5-1 ワークスペース・オブジェクトと同期化される演算子

同期対象: 演算子

同期基準: ワークスペース・オブジェクトのタイプ

キューブ

表、ビュー、マテリアライズド・ビュー、フラット・ファイル、ディメンションおよびキューブ

ディメンション

表、外部表、ビュー、マテリアライズド・ビュー、フラット・ファイル、ディメンションおよびキューブ

外部表

表、外部表、ビュー、マテリアライズド・ビュー、フラット・ファイル、ディメンションおよびキューブ

フラット・ファイル

表、外部表、ビュー、マテリアライズド・ビュー、フラット・ファイル、ディメンションおよびキューブ

キー参照

表のみ

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

表、外部表、ビュー、マテリアライズド・ビュー、ファイル、ディメンションおよびキューブ

マッピング後プロセス

変換のみ

マッピング前プロセス

変換のみ

順序

順序のみ

表

表、外部表、ビュー、マテリアライズド・ビュー、フラット・ファイル、ディメンションおよびキューブ

変換

変換のみ

ビュー

表、外部表、ビュー、マテリアライズド・ビュー、ファイル、ディメンションおよびキューブ

外部表演算子から同期化するとき、Warehouse Builderは、関連付けられたフラット・ファイルではなく、ワークスペース外部表のみに基づいて演算子を更新することに注意してください。

演算子からワークスペース・オブジェクトへの同期化

マッピングの演算子を変更した場合は、それらの変更をワークスペース・オブジェクトに伝播する必要があります。同期化によって、表、ビュー、マテリアライズド・ビュー、変換およびフラット・ファイルの各演算子の変更を伝播できます。

次のような理由により、演算子からワークスペース・オブジェクトへの同期化を実行します。

- 変更の伝播: 演算子の変更を関連するワークスペース・オブジェクトに伝播します。演算子または属性のビジネス名を変更すると、Warehouse Builderによってそのビジネス名の最初の30文字がバウンド名として伝播されます。

- ワークスペース・オブジェクトの置換: 同期化により、既存のワークスペース・オブジェクトを置換します。

演算子からの同期化は、他の演算子とワークスペース・オブジェクトとの依存関係には影響を与えません。

6 ターゲット・スキーマへの配布およびETLロジックの実行

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

- 配布について

- オブジェクトの配布

- ETLジョブの開始

配布について

配布は、Warehouse Builderリポジトリ内の論理オブジェクトから、ターゲット・ロケーション内に物理オブジェクトを作成するプロセスです。

マッピングまたはプロセス・フローの配布には、次の手順が含まれます。

- 必要に応じて、PL/SQL、SQL*LoaderまたはABAPスクリプトを生成します。

- スクリプトをデザイン・センターからコントロール・センターにコピーします。また、SQL*Loader制御ファイルもコントロール・センターにコピーします。

- 新しいコネクタを配布します。つまり、ロケーション間にデータベース・リンクとデータベース・ディレクトリを作成します。

マッピングまたはプロセス・フローの配布の後、スクリプトを明示的に開始する必要があります。

配布できるのは、ユーザーにCOMPILE権限があるオブジェクトのみです。デフォルトでは、リポジトリ内のすべてのオブジェクトに対してこの権限があります。ただし、リポジトリの所有者が異なるセキュリティ・ポリシーを設定している場合があります。

デザイン・センターのナビゲーション・ツリーから直接配布するか、またはコントロール・センター・マネージャを使用して配布できます。

注意:
オブジェクトは常にWarehouse Builderを使用して保守してください。配布した物理オブジェクトをSQLで手動で変更しないでください。そうしないと、論理オブジェクトと物理オブジェクトの同期がとれなくなり、予測できない結果を引き起こす可能性があります。

注意:
オブジェクトを配布するたびに、Warehouse Builderでは、すべての設計オブジェクトに対するすべての変更がリポジトリに自動的に保存されます。「プリファレンス」ダイアログ・ボックスの「コミットを要求」を選択すると、警告メッセージの表示を選択できます。

コントロール・センターの概要

コントロール・センターには、すべての配布に関する詳細情報が格納されます。次の情報が含まれており、オブジェクト単位またはジョブ単位でアクセスできます。

- 各オブジェクトの現在の配布ステータス

- 各オブジェクトに対するすべての配布試行の履歴

- 各マッピングおよびプロセス・フローに対するすべてのETL開始試行の履歴

- すべての配布ジョブからのメッセージの完全ログ

コントロール・センターは、ターゲット・ロケーションと同じデータベース内にスキーマとして実装されています。各リポジトリにはデフォルトのコントロール・センターがあり、これは、リポジトリ所有者のスキーマ内に作成されています。たとえば、REP_OWNERリポジトリの所有者には、REP_OWNERというスキーマがあり、このスキーマには、デザイン・センターとデフォルトのコントロール・センターの両方からのメタデータが格納されます。

ローカル・システムに配布するには、デフォルトのコントロール・センターを使用できます。または、別のシステムに配布するために、追加のコントロール・センターを作成できます。一度に1つのコントロール・センターのみアクティブにできます。

コントロール・センター・マネージャでは、配布のすべての側面を表示および管理できる総合的な配布コンソールが提供されます。ここから、アクティブな「コントロール・センター」に格納されている情報にアクセスできます。

リポジトリ・ブラウザを使用して、配布データ・レポートにアクセスすることもできます(Warehouse Builderのオンライン・ヘルプを参照)。

新規コントロール・センターを作成する手順

1. ロケーション・ナビゲータで、「コントロール・センター」を右クリックして「新規コントロール・センター」を選択します。
「コントロール・センターの作成」ダイアログ・ボックスが表示されます。

2. このダイアログ・ボックスを完了します。詳細は、「ヘルプ」ボタンをクリックしてください。

コントロール・センターは、構成の作成ウィザードを使用して作成することもできます。

コントロール・センターをアクティブにする手順

1. コントロール・センターを使用するように、構成を作成または編集します。

2. その構成をアクティブ化します。

配布の物理詳細の構成

Warehouse Builderでは、オブジェクトの論理設計が配布の物理詳細から分離されています。この分離は、構成パラメータに物理詳細を格納することによって実現します。構成と呼ばれるオブジェクトには、すべての構成設定が格納されます。各配布ロケーションには、それぞれのオブジェクト・パラメータに異なる設定を指定して、異なる構成を作成できます。

配布前に、ターゲット・オブジェクト、マッピングおよびモジュールの構成を確認してください。

オブジェクトが配布可能になる条件は、次のとおりです。

- そのターゲット・ロケーションが完全に定義され、有効であり、オブジェクトのモジュールに対して選択されている必要があります。

- その配布可能パラメータが選択されている(デフォルト)必要があります。

- 検証および生成がエラーなしに実行されている必要があります。

配布アクション

デザイン・センターで新規オブジェクトを定義すると、コントロール・センター・マネージャにそのオブジェクトがリストされます。各オブジェクトには表示可能なデフォルトの配布アクションがあります。このデフォルトは以前のアクションによって設定され、オブジェクトのタイプによって異なります。デフォルトは、コントロール・センター・マネージャで別の配布アクションを選択することで上書きできます。

次の配布アクションがあります。

- 作成: ターゲット・ロケーションにオブジェクトを作成します。指定した名前のオブジェクトがすでに存在している場合は、エラーが発生する可能性があります。

- アップグレード: 可能な場合、データを喪失することなくオブジェクトを変更します。アップグレードは、元に戻して再実行できます。このアクションは、スケジュールなど、一部のオブジェクト・タイプには使用できません。

- 削除: ターゲット・ロケーションからオブジェクトを削除します。

- 置換: オブジェクトを削除して再作成します。このアクションは、アップグレード・アクションより高速ですが、データはすべて削除されます。

配布プロセス

データ・システムのライフサイクル期間中は、通常、配布プロセスで次の手順を実行します。

1. オブジェクト設定および使用するコントロール・センターが指定された構成を選択します。

2. オブジェクトをターゲット・ロケーションに配布します。個別に配布、1つずつ順に配布、すべて一度に配布のいずれも可能です。

3. 配布の結果を確認します。オブジェクトの配布に失敗した場合は、問題を修正し、再試行してください。

4. ETLプロセスを開始します。

5. ユーザーの要求やソース・データの変更などにあわせて、ターゲット・オブジェクトの設計を変更します。

6. 変更したオブジェクトの配布アクションを「アップグレード」または「置換」に設定します。

7. これらの手順を繰り返します。

注意:
Warehouse Builderでは、配布前に、リポジトリに対するすべての変更が自動的に保存されます。

オブジェクトの配布

配布は、生成したコードを使用して、メタデータからターゲット・ロケーションに物理オブジェクトを作成するプロセスです。オブジェクトは、プロジェクト・ナビゲータから配布することも、コントロール・センター・マネージャを使用して配布することもできます。Warehouse Builderでは、オブジェクトを自動的に検証して生成します。

プロジェクト・エクスプローラからの配布は、デフォルト・アクションに制限されており、作成」、「置換」、「削除」または「更新」に設定されている可能性があります。デフォルト・アクションを上書きするには、配布プロセスを完全に制御するコントロール・センター・マネージャを使用します。

プロジェクト・ナビゲータから配布する手順

該当するオブジェクトを選択して、ツールバーの「配布」アイコンをクリックします。

ステータス・メッセージが、「デザイン・センター」ウィンドウの下部に表示されます。配布が完了したことを通知する場合は、配布前にプリファレンスで「配布完了メッセージの表示」を選択します。

コントロール・センター・マネージャを開く手順

1. プロジェクトを開きます。

2. 「ツール」メニューから「コントロール・センター・マネージャ」を選択します。

ETLジョブの開始

ETLとは、ソース・ロケーションからデータを抽出し、マッピングで定義されたように変換し、ターゲット・オブジェクトにロードするプロセスです。ETLを開始するときは、データをジョブとしてWarehouse Builderジョブ・キューに送信します。このジョブは、すぐに開始できます。また、Oracle Enterprise Managerのスケジューラなど、スケジューラを使用する場合は、スケジュールされた時間に開始できます。配布と同様に、ETLをプロジェクト・ナビゲータから開始することも、コントロール・センター・マネージャを使用して開始することもできます。SQLスクリプトを実行するWarehouse Builder外部のツールをして、ETLを開始することもできます。

プロジェクト・ナビゲータからETLを開始する手順

マッピングまたはプロセス・フローを選択して、「ファイル」メニューから「開始」を選択します。

データの表示

ETLを完了した後は、Warehouse Builder内のデータ・オブジェクトを確認し、結果が期待どおりであることを検証できます。

データを表示する手順

プロジェクト・ナビゲータで、オブジェクトを右クリックして「データ」を選択します。「データ・ビューア」が開き、オブジェクトの内容が表示されます。

第III部

データ・ウェアハウスのレポート作成

第III部では、データ・ウェアハウスの管理方法について説明します。内容は次のとおりです。

- 第7章「レポートおよび分析のSQL」

7 レポートおよび分析のSQL

この章では、ビジネス問合せから導出された効果的なビジネス・レポートの作成方法を説明します。この章の内容は次のとおりです。

- ビジネス問合せに応答するSQLアナリティック機能の使用

- パーティション外部結合を使用したスパースなデータの処理

- ビジネス問合せを単純化するWITH句の使用

ビジネス問合せに応答するSQLアナリティック機能の使用

Oracle Databaseでは、集計および分析SQL関数のファミリの導入によってSQLの分析処理機能を強化しています。これらの関数によって、ランキング、パーセンタイルおよび移動平均の計算など、次の問合せに応答できます。

- 上位10製品の国別売上は何ですか。

- 在庫のある製品の毎週の移動平均はどうですか。

- 総売上高の何パーセントが第4四半期に発生していますか。

- 第4四半期の平均割引は年間の平均割引よりどれくらい高いですか。

- 国内の精油所の20パーセントが閉鎖された場合、既存の精油所の収益性ランキングはどうなりますか。

集計関数は、合計の異なるタイプを導出でき、追加計算のこれらの合計を使用できるデータ・ウェアハウスの基礎となる部分です。データ・ウェアハウスの集計パフォーマンスを向上させるには、Oracle DatabaseはGROUP BY列に対するいくつかの拡張を提供します。CUBE、ROLLUP、GROUPINGおよびGROUPING SETS関数により、より早く簡単に問合せおよびレポート作成ができます。ROLLUP関数は、個人的で詳細なレベルからサマリー合計まで、集計レベルを上げながらSUM、COUNT、MAX、MINおよびAVGなどの集計を計算します。CUBE関数はROLLUPに似た拡張で、単一の文で集計可能なすべての組合せを計算できます。

分析関数は行のグループに基づいて集計値を計算します。これらの関数は各グループに対して複数の行を戻すという点で集計関数とは異なります。この行のグループはウィンドウと呼ばれます。このウィンドウを使用すると、移動平均や累積合計などを計算できます。行ウィンドウは各行に対して定義されます。このウィンドウでは現行の行の計算を実行するために使用する行の範囲を決定します。ウィンドウのサイズは時間などの論理間隔、または行の物理的な数に基づくことができます。一部の関数はウィンドウとのみ使用され、ウィンドウ関数として参照されます。

パフォーマンスを向上させるために集計関数と分析関数をそれぞれパラレルで実行することができ、これは複数のプロセスでこれらのすべての関数を同時に実行できることを意味します。こうした機能によって計算、分析およびレポート作成がより容易かつ効率的になるため、データ・ウェアハウスのパフォーマンス、スケーラビリティおよび簡易性が向上します。

高度なSQLおよびPL/SQL機能を活用でき、Oracle Databaseはビジネス問合せをSQLに変換します。この項では、これらの高度な機能について、次のとおり説明します。

- ROLLUP関数を使用したレポートへの合計の追加方法

- CUBE関数を使用した異なるレベルでの合計の分割方法

- GROUPING関数を使用した小計の追加方法

- GROUPING SETS関数を使用した集計の結合方法

- RANK関数を使用したランキングの計算方法

- 合計に対する相対的な寄与率の計算方法

- ウィンドウ関数を使用した行間計算の実行方法

- ウィンドウ関数を使用した移動平均の計算方法

ROLLUP関数を使用したレポートへの合計の追加方法

ROLLUP関数によって、SELECT文で総計やディメンションの特定のグループを横断する複数の小計レベルを計算できます。ROLLUP関数は、GROUP BY句の単純な拡張であるため、この構文は簡単に使用できます。ROLLUP関数は非常に効率的で、問合せにかかるオーバーヘッドは最小限に抑えられます。ROLLUP関数のアクションは単純で、最も詳細なレベルから総計まで、ROLLUP関数で指定されたグループ・リストに従ってロールアップする小計を作成します。ROLLUP関数は引数として、グルーピング列の順序付けリストを取ります。最初に、GROUP BY句で指定された標準の集計値を計算します。次に、グルーピング列のリストを右から左に移動しながら、順番に高いレベルの小計を作成します。最後に、総計を作成します。

ROLLUP関数を使用するとき

タスクに小計が含まれる場合、特に小計が時間または地理などの階層ディメンションに基づいている場合、ROLLUP関数は有効です。また、ROLLUP関数によって、マテリアライズド・ビューのメンテナンスを簡素化および高速化することもできます。

例: ROLLUP関数の使用

ビジネス・レポートの準備時に共通して要求されるのは、収入額順で、異なる製品カテゴリにわたる四半期の総売上高の検索です。次の問合せはこれを達成し、後に実行するより複雑な問合せの構築の開始点に使用されます。

ROLLUP関数を使用する手順

SELECT t.calendar_quarter_desc quarter
, p.prod_category category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY t.calendar_quarter_desc, p.prod_category
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER  CATEGORY                                  REVENUE
-------  ------------------------------            --------------
2001-01  Software/Other                               $860,819.81
2001-01  Electronics                                $1,239,287.71
2001-01  Hardware                                   $1,301,343.45
2001-01  Photo                                      $1,370,706.38
2001-01  Peripherals and Accessories                $1,774,940.09
2001-02  Software/Other                               $872,157.38
2001-02  Electronics                                $1,144,187.90
2001-02  Hardware                                   $1,557,059.59
2001-02  Photo                                      $1,563,475.51
2001-02  Peripherals and Accessories                $1,785,588.01
2001-03  Software/Other                               $877,630.85
2001-03  Electronics                                $1,017,536.82
2001-03  Photo                                      $1,607,315.63
2001-03  Hardware                                   $1,651,454.29
2001-03  Peripherals and Accessories                $2,042,061.04
2001-04  Software/Other                               $943,296.36
2001-04  Hardware                                   $1,174,512.68
2001-04  Electronics                                $1,303,838.52
2001-04  Photo                                      $1,792,131.39
2001-04  Peripherals and Accessories                $2,257,118.57

この問合せは便利ですが、同じレポート上で異なるカテゴリの総計を確認する必要がある可能性があります。次の例は、ROLLUP関数を使用して、元の問合せに総計を追加する方法を示しています。

SELECT t.calendar_quarter_desc quarter
, p.prod_category category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY ROLLUP(t.calendar_quarter_desc, p.prod_category)
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER   CATEGORY                                   REVENUE
-------   ------------------------------             -------------
2001-01   Software/Other                               $860,819.81
2001-01   Electronics                                $1,239,287.71
2001-01   Hardware                                   $1,301,343.45
2001-01   Photo                                      $1,370,706.38
2001-01   Peripherals and Accessories                $1,774,940.09
2001-01                                              $6,547,097.44
2001-02   Software/Other                               $872,157.38
2001-02   Electronics                                $1,144,187.90
2001-02   Hardware                                   $1,557,059.59
2001-02   Photo                                      $1,563,475.51
2001-02   Peripherals and Accessories                $1,785,588.01
2001-02                                              $6,922,468.39
2001-03   Software/Other                               $877,630.85
2001-03   Electronics                                $1,017,536.82
2001-03   Photo                                      $1,607,315.63
2001-03   Hardware                                   $1,651,454.29
2001-03   Peripherals and Accessories                $2,042,061.04
2001-03                                              $7,195,998.63
2001-04   Software/Other                               $943,296.36
2001-04   Hardware                                   $1,174,512.68
2001-04   Electronics                                $1,303,838.52
2001-04   Photo                                      $1,792,131.39
2001-04   Peripherals and Accessories                $2,257,118.57
2001-04                                              $7,470,897.52
$28,136,461.98

CUBE関数を使用した異なるレベルでの合計の分割方法

CUBE関数は指定されたグループ化列の集合を取り、それらが取り得るすべての組合せに対して小計を作成します。多次元分析によって、CUBE関数は指定されたディメンションを持つデータ・キューブに対して計算されるすべての小計を生成します。CUBE(time, region, department)を指定した場合、結果セットには同等のROLLUP関数および追加の組合せに含まれるすべての値が含まれます。

CUBE関数を使用するとき

複数の表にわたるレポートを必要とする状況では、CUBE関数の使用を検討してください。複数の表にわたるレポートに必用なデータは、CUBE関数を使用する単一のSELECT文で生成できます。ROLLUPと同様に、CUBE関数もマテリアライズド・ビューの生成に便利です。CUBE関数を含む問合せがパラレルに実行される場合は、マテリアライズド・ビューの移入が速くなることに注意してください。

例: CUBE関数の使用

四半期の合計に加えて、選択した期間における様々な製品カテゴリの合計も取得する必要がある場合があります。次の例に示すように、CUBE関数を使用してこの計算を行うことができます。

CUBE関数を使用する手順

SELECT t.calendar_quarter_desc quarter
, p.prod_category category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY CUBE(t.calendar_quarter_desc, p.prod_category)
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER   CATEGORY                                   REVENUE
-------   ------------------------------             -------------
2001-01   Software/Other                               $860,819.81
2001-01   Electronics                                $1,239,287.71
2001-01   Hardware                                   $1,301,343.45
2001-01   Photo                                      $1,370,706.38
2001-01   Peripherals and Accessories                $1,774,940.09
2001-01                                              $6,547,097.44
2001-02   Software/Other                               $872,157.38
2001-02   Electronics                                $1,144,187.90
2001-02   Hardware                                   $1,557,059.59
2001-02   Photo                                      $1,563,475.51
2001-02   Peripherals and Accessories                $1,785,588.01
2001-02                                              $6,922,468.39
2001-03   Software/Other                               $877,630.85
2001-03   Electronics                                $1,017,536.82
2001-03   Photo                                      $1,607,315.63
2001-03   Hardware                                   $1,651,454.29
2001-03   Peripherals and Accessories                $2,042,061.04
2001-03                                              $7,195,998.63
2001-04   Software/Other                               $943,296.36
2001-04   Hardware                                   $1,174,512.68
2001-04   Electronics                                $1,303,838.52
2001-04   Photo                                      $1,792,131.39
2001-04   Peripherals and Accessories                $2,257,118.57
2001-04                                              $7,470,897.52
Software/Other                             $3,553,904.40
Electronics                                $4,704,850.95
Hardware                                   $5,684,370.01
Photo                                      $6,333,628.91
Peripherals and Accessories                $7,859,707.71
$28,136,461.98

GROUPING関数を使用した小計の追加方法

ROLLUPおよびCUBE関数を使用する際には、2つの課題があります。第一に、どの結果セット行が小計であるかをプログラム上でどのように判断し、指定された小計の正確な小計レベルをどのように探し出すかということです。合計に対する割合を計算する場合に小計を使用する必要があるため、どの行が求める小計であるかを判別する方法が必要です。第2に、格納されるNULL値およびROLLUP、またはCUBE関数によって作成されるNULL値の両方が問合せ結果に含まれる場合、どう処理するかという問題です。この2つをどのように区別するかが問題になります。

この問題はGROUPING関数で処理します。単一の列を引数として使用し、ROLLUPまたはCUBE関数により作成されたNULL値が発生した場合、GROUPING関数は1を戻します。つまり、NULL値が小計の行であることを示す場合、GROUPING関数は1を戻します。格納されたNULL値を含むその他のタイプの値では0を戻します。

GROUPING関数を使用するとき

NULL値またはROLLUPまたはCUBE操作で作成されたNULL 値を処理する必要がある場合、GROUPING関数を使用します。NULL値を使用する1つの理由に、NULLフィールドに説明を置くことです。たとえば、番号が総計を示すテキストなどです。

例: GROUPING関数の使用

値が総計を示している場合にわかりにくいため、レポート内の説明の列がさらに必要になる場合があります。GROUPING関数を使用すると、次の例のように、問合せ結果に総計を示すラベルを挿入することができます。

GROUPING関数を使用する手順

SELECT DECODE(GROUPING(t.calendar_quarter_desc)
, 0, t.calendar_quarter_desc
, 1, 'TOTAL'
) quarter
, DECODE(GROUPING(p.prod_category)
, 0,  p.prod_category
, 1, 'TOTAL'
) category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY CUBE(t.calendar_quarter_desc, p.prod_category)
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER   CATEGORY                           REVENUE
-------   ------------------------------     -------------
2001-01   Software/Other                       $860,819.81
2001-01   Electronics                        $1,239,287.71
2001-01   Hardware                           $1,301,343.45
2001-01   Photo                              $1,370,706.38
2001-01   Peripherals and Accessories        $1,774,940.09
2001-01   TOTAL                              $6,547,097.44
2001-02   Software/Other                       $872,157.38
2001-02   Electronics                        $1,144,187.90
2001-02   Hardware                           $1,557,059.59
2001-02   Photo                              $1,563,475.51
2001-02   Peripherals and Accessories        $1,785,588.01
2001-02   TOTAL                              $6,922,468.39
2001-03   Software/Other                       $877,630.85
2001-03   Electronics                        $1,017,536.82
2001-03   Photo                              $1,607,315.63
2001-03   Hardware                           $1,651,454.29
2001-03   Peripherals and Accessories        $2,042,061.04
2001-03   TOTAL                              $7,195,998.63
2001-04   Software/Other                       $943,296.36
2001-04   Hardware                           $1,174,512.68
2001-04   Electronics                        $1,303,838.52
2001-04   Photo                              $1,792,131.39
2001-04   Peripherals and Accessories        $2,257,118.57
2001-04   TOTAL                              $7,470,897.52
TOTAL     Software/Other                     $3,553,904.40
TOTAL     Electronics                        $4,704,850.95
TOTAL     Hardware                           $5,684,370.01
TOTAL     Photo                              $6,333,628.91
TOTAL     Peripherals and Accessories        $7,859,707.71
TOTAL     TOTAL                             $28,136,461.98

GROUPING SETS関数を使用した集計の結合方法

GROUP BY句でGROUPING SETS関数を使用して、作成するグループの集合を選択的に指定できます。これにより、データ・キューブ全体を計算せずに、複数のディメンションにまたがる正確な指定ができます。これは、すべてのディメンションの総計が必要ではないことを意味します。

GROUPING SETS関数を使用するとき

データ・キューブ内の特定の小計が必要ですべての小計が入手できない場合、GROUPING SETS関数を使用します。

例: GROUPING SETS関数の使用

販売チャネルに基づく営業番号の総計を参照する場合があります。チャネル・クラスごとの総計を取得するため別の問合せを追加するかわりに、次の例のように、GROUPING SETS関数を使用できます。

GROUPING SETS関数を使用する手順

SELECT DECODE(GROUPING(t.calendar_quarter_desc)
, 0, t.calendar_quarter_desc
, 1, 'TOTAL'
) quarter
, DECODE(GROUPING(c.channel_class)
, 0, c.channel_class
, 1 , '--all--'
) channel
, DECODE(GROUPING(p.prod_category)
, 0,  p.prod_category
, 1, 'TOTAL'
) category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, channels c
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   c.channel_id = s.channel_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY GROUPING SETS(c.channel_class,
CUBE(t.calendar_quarter_desc, p.prod_category))
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER  CHANNEL       CATEGORY                     REVENUE
-------  ------------- ---------------------------- -------------
2001-01  --all--       Software/Other                 $860,819.81
2001-01  --all--       Electronics                  $1,239,287.71
2001-01  --all--       Hardware                     $1,301,343.45
2001-01  --all--       Photo                        $1,370,706.38
2001-01  --all--       Peripherals and Accessories  $1,774,940.09
2001-01  --all--       TOTAL                        $6,547,097.44
2001-02  --all--       Software/Other                 $872,157.38
2001-02  --all--       Electronics                  $1,144,187.90
2001-02  --all--       Hardware                     $1,557,059.59
2001-02  --all--       Photo                        $1,563,475.51
2001-02  --all--       Peripherals and Accessories  $1,785,588.01
2001-02  --all--       TOTAL                        $6,922,468.39
2001-03  --all--       Software/Other                 $877,630.85
2001-03  --all--       Electronics                  $1,017,536.82
2001-03  --all--       Photo                        $1,607,315.63
2001-03  --all--       Hardware                     $1,651,454.29
2001-03  --all--       Peripherals and Accessories  $2,042,061.04
2001-03  --all--       TOTAL                        $7,195,998.63
2001-04  --all--       Software/Other                 $943,296.36
2001-04  --all--       Hardware                     $1,174,512.68
2001-04  --all--       Electronics                  $1,303,838.52
2001-04  --all--       Photo                        $1,792,131.39
2001-04  --all--       Peripherals and Accessories  $2,257,118.57
2001-04  --all--       TOTAL                        $7,470,897.52
TOTAL    --all--       Software/Other               $3,553,904.40
TOTAL    --all--       Electronics                  $4,704,850.95
TOTAL    --all--       Hardware                     $5,684,370.01
TOTAL    --all--       Photo                        $6,333,628.91
TOTAL    Indirect      TOTAL                        $6,709,496.66
TOTAL    --all--       Peripherals and Accessories  $7,859,707.71
TOTAL    Others        TOTAL                        $8,038,529.96
TOTAL    Direct        TOTAL                       $13,388,435.36
TOTAL    --all--       TOTAL                       $28,136,461.98

RANK関数を使用したランキングの計算方法

ビジネス情報の処理には、複雑なランキング、小計、移動平均およびリード/ラグ比較を含む高度な計算が要求されます。これらの集計および分析タスクはビジネス・インテリジェンス問合せに不可欠であり、ウィンドウ関数の使用によって解決します。

RANK関数を使用するとき

複雑な問合せを実行したり問合せ結果を分析する場合には、RANK関数を使用します。

例: RANK関数の使用

四半期の収入番号のランクを示す追加の列を確認する場合があります。次の例では、RANK関数を使用してこれを実行しています。

RANK関数を使用する手順

SELECT DECODE(GROUPING(t.calendar_quarter_desc)
, 0, t.calendar_quarter_desc
, 1, 'TOTAL'
) quarter
, DECODE(GROUPING(t.calendar_quarter_desc) + GROUPING(p.prod_category)
, 0, RANK() OVER (PARTITION BY t.calendar_quarter_desc
ORDER BY SUM(s.amount_sold))
, 1, null
) ranking
, DECODE(GROUPING(c.channel_class)
, 0, c.channel_class
, 1 , '--all--'
) channel
, DECODE(GROUPING(p.prod_category)
, 0,  p.prod_category
, 1, 'TOTAL'
) category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
FROM times t
, products p
, channels c
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   c.channel_id = s.channel_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY GROUPING SETS(c.channel_class,
CUBE(t.calendar_quarter_desc, p.prod_category))
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER  RANKING  CHANNEL    CATEGORY                       REVENUE
-------  -------  --------   ----------------------------   --------------
2001-01        1  --all--    Software/Other                    $860,819.81
2001-01        2  --all--    Electronics                     $1,239,287.71
2001-01        3  --all--    Hardware                        $1,301,343.45
2001-01        4  --all--    Photo                           $1,370,706.38
2001-01        5  --all--    Peripherals and Accessories     $1,774,940.09
2001-01           --all--    TOTAL                           $6,547,097.44
2001-02        1  --all--    Software/Other                    $872,157.38
2001-02        2  --all--    Electronics                     $1,144,187.90
2001-02        3  --all--    Hardware                        $1,557,059.59
2001-02        4  --all--    Photo                           $1,563,475.51
2001-02        5  --all--    Peripherals and Accessories     $1,785,588.01
2001-02           --all--    TOTAL                           $6,922,468.39
2001-03        1  --all--    Software/Other                    $877,630.85
2001-03        2  --all--    Electronics                     $1,017,536.82
2001-03        3  --all--    Photo                           $1,607,315.63
2001-03        4  --all--    Hardware                        $1,651,454.29
2001-03        5  --all--    Peripherals and Accessories     $2,042,061.04
2001-03           --all--    TOTAL                           $7,195,998.63
2001-04        1  --all--    Software/Other                    $943,296.36
2001-04        2  --all--    Hardware                        $1,174,512.68
2001-04        3  --all--    Electronics                     $1,303,838.52
2001-04        4  --all--    Photo                           $1,792,131.39
2001-04        5  --all--    Peripherals and Accessories     $2,257,118.57
2001-04           --all--    TOTAL                           $7,470,897.52
TOTAL             --all--    Software/Other                  $3,553,904.40
TOTAL             --all--    Electronics                     $4,704,850.95
TOTAL             --all--    Hardware                        $5,684,370.01
TOTAL             --all--    Photo                           $6,333,628.91
TOTAL             Indirect   TOTAL                           $6,709,496.66
TOTAL             --all--    Peripherals and Accessories     $7,859,707.71
TOTAL             Others     TOTAL                           $8,038,529.96
TOTAL             Direct     TOTAL                          $13,388,435.36
TOTAL             --all--    TOTAL                          $28,136,461.98

In this example, the PARTITION BY clause defines the boundaries for the RANK function.

合計に対する相対的な寄与率の計算方法

共通のビジネス・インテリジェンス要求は、特定の時間間隔に基づく総収入に対する各製品カテゴリの寄与率を計算します。

例: 総計に対する相対的な寄与率の計算

四半期ベースで収入番号の差異を取得します。次の例のように、PARTITION BY製品カテゴリを持つウィンドウ関数を使用して実行できます。

総計に対する相対的な寄与率を計算する手順

SELECT DECODE(GROUPING(t.calendar_quarter_desc)
, 0, t.calendar_quarter_desc
, 1, 'TOTAL'
) quarter
, DECODE(GROUPING(t.calendar_quarter_desc) + GROUPING(p.prod_category)
, 0, RANK() OVER (PARTITION BY t.calendar_quarter_desc
ORDER BY SUM(s.amount_sold))
, 1, null
) RANKING
, DECODE(GROUPING(c.channel_class)
, 0, c.channel_class
, 1 , '--all--'
) channel
, DECODE(GROUPING(p.prod_category)
, 0,  p.prod_category
, 1, 'TOTAL'
) category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
, TO_CHAR(100 * RATIO_TO_REPORT(SUM(s.amount_sold))
OVER (PARTITION BY (TO_CHAR(GROUPING(p.prod_category) ||
t.calendar_quarter_desc))),'990D0') percent
FROM times t
, products p
, channels c
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   c.channel_id = s.channel_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY GROUPING SETS(c.channel_class,
CUBE(t.calendar_quarter_desc, p.prod_category))
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER  RANKING  CHANNEL  CATEGORY         REVENUE         PERC
-------  -------  -------  -------------    ------------    ----
2001-01        1  --all--  Software/Other     $860,819.81   13.1
2001-01        2  --all--  Electronics      $1,239,287.71   18.9
2001-01        3  --all--  Hardware         $1,301,343.45   19.9
2001-01        4  --all--  Photo            $1,370,706.38   20.9
2001-01        5  --all--  Peripherals      $1,774,940.09   27.1
2001-01           --all--  TOTAL            $6,547,097.44  100.0
2001-02        1  --all--  Software/Other     $872,157.38   12.6
2001-02        2  --all--  Electronics      $1,144,187.90   16.5
2001-02        3  --all--  Hardware         $1,557,059.59   22.5
2001-02        4  --all--  Photo            $1,563,475.51   22.6
2001-02        5  --all--  Peripherals      $1,785,588.01   25.8
2001-02           --all--  TOTAL            $6,922,468.39  100.0
2001-03        1  --all--  Software/Other     $877,630.85   12.2
2001-03        2  --all--  Electronics      $1,017,536.82   14.1
2001-03        3  --all--  Photo            $1,607,315.63   22.3
2001-03        4  --all--  Hardware         $1,651,454.29   22.9
2001-03        5  --all--  Peripherals      $2,042,061.04   28.4
2001-03           --all--  TOTAL            $7,195,998.63  100.0
2001-04        1  --all--  Software/Other     $943,296.36   12.6
2001-04        2  --all--  Hardware         $1,174,512.68   15.7
2001-04        3  --all--  Electronics      $1,303,838.52   17.5
2001-04        4  --all--  Photo            $1,792,131.39   24.0
2001-04        5  --all--  Peripherals      $2,257,118.57   30.2
2001-04           --all--  TOTAL            $7,470,897.52  100.0
TOTAL             --all--  Software/Other   $3,553,904.40   12.6
TOTAL             --all--  Electronics      $4,704,850.95   16.7
TOTAL             --all--  Hardware         $5,684,370.01   20.2
TOTAL             --all--  Photo            $6,333,628.91   22.5
TOTAL            Indirect  TOTAL            $6,709,496.66   11.9
TOTAL             --all--  Peripherals      $7,859,707.71   27.9
TOTAL              Others  TOTAL            $8,038,529.96   14.3
TOTAL              Direct  TOTAL           $13,388,435.36   23.8
TOTAL             --all--  TOTAL           $28,136,461.98   50.0

"Peripherals" was used instead of "Peripherals and Accessories" to save space.

ウィンドウ関数を使用した行間計算の実行方法

ビジネス・インテリジェンスに共通する問題は、特定の結果がどのように他の結果と関連しているかということです。単一問合せでこれを行うには、ウィンドウ関数を使用して単一の文で行間計算を実行できます。

例: 行間計算の実行

四半期ごとに、総収入に対する各製品カテゴリの寄与率を調べる場合があります。次の例に示すように、ウィンドウ関数RATIO_TO_REPORTを使用してこの結果を求めることができます。四半期ごとのRATIO_TO_REPORTから総計を除外するには、GROUPING(p.prod_category)を持つ連結を使用する必要があることに注意してください。

行間計算を行う手順

SELECT DECODE(GROUPING(t.calendar_quarter_desc)
, 0, t.calendar_quarter_desc
, 1, 'TOTAL'
) quarter
, DECODE(GROUPING(t.calendar_quarter_desc) + GROUPING(p.prod_category)
, 0, RANK() OVER (PARTITION BY t.calendar_quarter_desc
ORDER BY SUM(s.amount_sold))
, 1, null
) RANKING
, DECODE(GROUPING(c.channel_class)
, 0, c.channel_class
, 1 , '--all--'
) channel
, DECODE(GROUPING(p.prod_category)
, 0,  p.prod_category
, 1, 'TOTAL'
) category
, TO_CHAR(SUM(s.amount_sold),'L999G999G990D00') revenue
, TO_CHAR(100 * RATIO_TO_REPORT(SUM(s.amount_sold))
OVER (PARTITION BY (TO_CHAR(GROUPING(p.prod_category) ||
t.calendar_quarter_desc))),'990D0') percent
, DECODE(GROUPING(t.calendar_quarter_desc) + GROUPING(p.prod_category)
, 0, TO_CHAR(SUM(s.amount_sold) - LAG(SUM(s.amount_sold),1)
OVER (PARTITION BY p.prod_category
ORDER BY t.calendar_quarter_desc),'L999G990D00')
, 1, null
) q_q_diff
FROM times t
, products p
, channels c
, sales s
WHERE t.time_id = s.time_id
AND   p.prod_id = s.prod_id
AND   c.channel_id = s.channel_id
AND   s.time_id BETWEEN TO_DATE('01-JAN-2001','dd-MON-yyyy')
AND TO_DATE('31-DEC-2001','dd-MON-yyyy')
GROUP BY GROUPING SETS(c.channel_class,
CUBE(t.calendar_quarter_desc, p.prod_category))
ORDER BY t.calendar_quarter_desc
, SUM(s.amount_sold);

QUARTER  RANKING  CHANNEL  CATEGORY         REVENUE         PERC     Q_Q_DIFF
-------  -------  -------  -------------    ------------    ----     ----------
2001-01        1  --all--  Software/Other     $860,819.81   13.1
2001-01        2  --all--  Electronics      $1,239,287.71   18.9
2001-01        3  --all--  Hardware         $1,301,343.45   19.9
2001-01        4  --all--  Photo            $1,370,706.38   20.9
2001-01        5  --all--  Peripherals      $1,774,940.09   27.1
2001-01           --all--  TOTAL            $6,547,097.44  100.0
2001-02        1  --all--  Software/Other     $872,157.38   12.6      $11,337.57
2001-02        2  --all--  Electronics      $1,144,187.90   16.5     -$95,099.81
2001-02        3  --all--  Hardware         $1,557,059.59   22.5     $255,716.14
2001-02        4  --all--  Photo            $1,563,475.51   22.6     $192,769.13
2001-02        5  --all--  Peripherals      $1,785,588.01   25.8      $10,647.92
2001-02           --all--  TOTAL            $6,922,468.39  100.0
2001-03        1  --all--  Software/Other     $877,630.85   12.2       $5,473.47
2001-03        2  --all--  Electronics      $1,017,536.82   14.1    -$126,651.08
2001-03        3  --all--  Photo            $1,607,315.63   22.3      $43,840.12
2001-03        4  --all--  Hardware         $1,651,454.29   22.9      $94,394.70
2001-03        5  --all--  Peripherals      $2,042,061.04   28.4     $256,473.03
2001-03           --all--  TOTAL            $7,195,998.63  100.0
2001-04        1  --all--  Software/Other     $943,296.36   12.6      $65,665.51
2001-04        2  --all--  Hardware         $1,174,512.68   15.7    -$476,941.61
2001-04        3  --all--  Electronics      $1,303,838.52   17.5     $286,301.70
2001-04        4  --all--  Photo            $1,792,131.39   24.0     $184,815.76
2001-04        5  --all--  Peripherals      $2,257,118.57   30.2     $215,057.53
2001-04           --all--  TOTAL            $7,470,897.52  100.0
TOTAL             --all--  Software/Other   $3,553,904.40   12.6
TOTAL             --all--  Electronics      $4,704,850.95   16.7
TOTAL             --all--  Hardware         $5,684,370.01   20.2
TOTAL             --all--  Photo            $6,333,628.91   22.5
TOTAL            Indirect  TOTAL            $6,709,496.66   11.9
TOTAL             --all--  Peripherals      $7,859,707.71   27.9
TOTAL              Others  TOTAL            $8,038,529.96   14.3
TOTAL              Direct  TOTAL           $13,388,435.36   23.8
TOTAL             --all--  TOTAL           $28,136,461.98   50.0

"Peripherals" was used instead of "Peripherals and Accessories" to save space.

ウィンドウ関数を使用した移動平均の計算方法

ウィンドウ関数を使用して移動集計を作成できます。移動関数は物理行の数に基づくか、論理時間間隔である可能性があります。ウィンドウ関数はPARTITIONキーワードを使用し、パーティションの各行に対してデータのウィンドウの変動を定義できます。このウィンドウでは現行の行の計算を実行するために使用する行の範囲を決定します。ウィンドウ・サイズは行の物理的な数または時間などの論理間隔に基づきます。ウィンドウには開始行および終了行が含まれます。ウィンドウは、その定義に応じて、片方の端または両方の端で移動できます。たとえば、累積SUM関数を定義したウィンドウには、パーティションの最初の行に固定された開始行が含まれ、終了行は開始点からパーティションの最後の行までスライドします。反対に、移動平均を定義したウィンドウには開始点と終了点の変動が含まれるため、定数の物理的範囲または論理的範囲が維持されます。

ウィンドウ関数は一般的に、移動および累積バージョンのSUM、AVERAGE、COUNT、MAX、MIN、および他の多くの関数の計算に使用されます。また、問合せのSELECT句、ORDER BY句でのみ使用できます。ウィンドウ関数には、ウィンドウで最初の値を戻すFIRST_VALUE関数、およびウィンドウで最終値を戻すLAST_VALUE関数が含まれます。これらの関数によって自己結合なしに表内の複数行にアクセスできます。

例: 移動平均の計算

次の例は、論理的な時間間隔を使用した、各製品の製品収入の7日間の変動平均を取得する問合せを示しています。

変動平均を計算する手順は、次のとおりです。

SELECT time_id
, prod_name
, TO_CHAR(revenue,'L999G990D00') revenue
, TO_CHAR(AVG(revenue) OVER (PARTITION BY prod_name ORDER BY time_id
RANGE INTERVAL '7' DAY PRECEDING),'L999G990D00') mv_7day_avg
FROM
( SELECT s.time_id, p.prod_name, SUM(s.amount_sold) revenue
FROM products p
, sales s
WHERE p.prod_id = s.prod_id
AND s.time_id BETWEEN TO_DATE('25-JUN-2001','dd-MON-yyyy')
AND TO_DATE('16-JUL-2001','dd-MON-yyyy')
AND p.prod_name LIKE '%Memory%'
AND p.prod_category = 'Photo'
GROUP BY s.time_id, p.prod_name
)
ORDER BY time_id, prod_name;

TIME_ID     PROD_NAME           REVENUE             MV_7DAY_AVG
---------   -----------------   ------------------  --------------
26-JUN-01   256MB Memory Card              $560.15         $560.15
30-JUN-01   256MB Memory Card              $844.00         $702.08
02-JUL-01   128MB Memory Card            $3,283.74       $3,283.74
02-JUL-01   256MB Memory Card            $3,903.32       $1,769.16
03-JUL-01   256MB Memory Card              $699.37       $1,501.71
08-JUL-01   128MB Memory Card            $3,283.74       $3,283.74
08-JUL-01   256MB Memory Card            $3,903.32       $2,835.34
10-JUL-01   256MB Memory Card              $138.82       $1,580.50

パーティション外部結合を使用したスパースなデータの処理

データは通常、スパースな形式で格納されています。つまり、ディメンション値の特定の組合せで値が存在しない場合、ファクト表(売上などの重要なファクトを含むデータ・ウェアハウスの表)には行が存在していません。しかし、ファクト・データが存在しない場合でも、ディメンション値のすべての組合せの行を表示し、データを稠密な形式で表示する必要がある場合があります。たとえば、製品が特定の期間販売されていない場合でも、その期間の売上値をゼロとして製品の横に表示する場合などです。さらに、データが時間ディメンションに沿って稠密であれば、時系列の計算を簡単に実行できます。これは、稠密なデータが期間ごとに一定数の行を占めているため、物理オフセットを指定した分析ウィンドウ関数の使用が単純化されるためです。

データの稠密化は、スパース・データを稠密な形式に変換するプロセスです。スパース性の問題を解決するために、パーティション外部結合を使用して時系列または他のディメンションとのギャップを埋めることができます。このタイプの結合は問合せで定義した各論理パーティションに外部結合を適用することで、従来の外部結合の構文を拡張したものです。Oracle Databaseは、PARTITION BY句で指定した式に基づいて、問合せの行を論理的にパーティション化します。パーティション外部結合の結果は、結合のもう一方の表を含む論理的にパーティション化された表にある各パーティションの外部結合のUNION操作です。時間ディメンションのみではなく他のディメンションのギャップを埋めるためにも、このタイプの結合を使用してください。

パーティション外部結合を使用するとき

結果セットの欠落した行を埋める場合または時系列計算を処理する場合、パーティション外部結合を使用します。

例: パーティション外部結合の使用

特定の製品の数週間の売上を表示する必要がある場合があります。この例では、フォト・カテゴリのメモリー・カードを使用します。これらの製品は頻繁に売れるものではなく、数週間売れないこともあるためです。簡単に比較するため、次の例のように、パーティション外部結合を使用してデータを稠密にする必要があります。

パーティション外部結合を使用する手順は、次のとおりです。

SELECT tim.week_ending_day
, rev.prod_name product
, nvl(SUM(rev.amount_sold),0) revenue
FROM (SELECT p.prod_name, s.time_id, s.amount_sold
FROM products p
, sales s
WHERE s.prod_id = p.prod_id
AND p.prod_category = 'Photo'
AND p.prod_name LIKE '%Memory%'
AND s.time_id BETWEEN TO_DATE('25-JUN-2001','dd-MON-yyyy')
AND TO_DATE('16-JUL-2001','dd-MON-yyyy')
) rev
PARTITION BY (prod_name)
RIGHT OUTER JOIN (SELECT time_id, week_ending_day FROM times
WHERE week_ending_day
BETWEEN TO_DATE('01-JUL-2001','dd-MON-yyyy')
AND TO_DATE('16-JUL-2001','dd-MON-yyyy')
) tim
ON (rev.time_id = tim.time_id)
GROUP BY tim.week_ending_day
, rev.prod_name
ORDER BY tim.week_ending_day
, rev.prod_name;

WEEK_ENDI   PRODUCT                                   REVENUE
---------   ----------------------------------------  ----------
01-JUL-01   128MB Memory Card                                  0
01-JUL-01   256MB Memory Card                            1404.15
08-JUL-01   128MB Memory Card                            6567.48
08-JUL-01   256MB Memory Card                            8506.01
15-JUL-01   128MB Memory Card                                  0
15-JUL-01   256MB Memory Card                             138.82

ビジネス問合せを単純化するWITH句の使用

異なるタイプの結合およびウィンドウ関数を活用して多くの表にアクセスする問合せは、複雑になります。WITH句を使用すると、問合せの増分的な構築によりこの複雑さを解消できます。複雑な問合せで問合せブロックが複数回発生する場合、SELECT文の同じ問合せブロックを再使用できます。Oracle Databaseは問合せブロックの結果を取得して、ユーザーの一時表領域に結果を格納します。

WITH句を使用するとき

同じ問合せブロックに対して複数の参照が問合せに含まれ、結合および集計がある場合、WITH句を使用します。

例: WITH句の使用

2001年7月締めの最初の3週間のフォト・カテゴリのメモリー・カード製品の売上を比較すると想定します。次の問合せはこの期間に売れなかった一部の製品を考慮し、前の週と関連する売上で増加または減少を戻します。最終的に、問合せは特定の週におけるメモリー・カードの売上に対する寄与率の割合を取得します。WITH句の使用のために、問合せの個々のセクションの複雑さは解消されます。

WITH句を使用する手順は、次のとおりです。

WITH sales_numbers AS
( SELECT s.prod_id, s.amount_sold, t.week_ending_day
FROM sales s
, times t
, products p
WHERE s.time_id = t.time_id
AND s.prod_id = p.prod_id
AND p.prod_category = 'Photo'
AND p.prod_name LIKE '%Memory%'
AND t.week_ending_day BETWEEN TO_DATE('01-JUL-2001','dd-MON-yyyy')
AND TO_DATE('16-JUL-2001','dd-MON-yyyy')
)
, product_revenue AS
( SELECT p.prod_name product, s.week_ending_day, SUM(s.amount_sold) revenue
FROM products p
LEFT OUTER JOIN (SELECT prod_id, amount_sold, week_ending_day
FROM sales_numbers) s
ON (s.prod_id = p.prod_id)
WHERE p.prod_category = 'Photo'
AND p.prod_name LIKE '%Memory%'
GROUP BY p.prod_name, s.week_ending_day
)
, weeks AS
( SELECT distinct week_ending_day week FROM times WHERE week_ending_day
BETWEEN TO_DATE('01-JUL-2001','dd-MON-yyyy')
AND TO_DATE('16-JUL-2001','dd-MON-yyyy')
)
, complete_product_revenue AS
( SELECT w.week, pr.product, nvl(pr.revenue,0) revenue
FROM product_revenue pr
PARTITION BY (product)
RIGHT OUTER JOIN weeks w
ON (w.week = pr.week_ending_day)
)
SELECT week
, product
, TO_CHAR(revenue,'L999G990D00') revenue
, TO_CHAR(revenue - lag(revenue,1) OVER (PARTITION BY product
ORDER BY week),'L999G990D00') w_w_diff
, TO_CHAR(100 * RATIO_TO_REPORT(revenue) OVER (PARTITION BY week),'990D0') percentage
FROM complete_product_revenue
ORDER BY week, product;

WEEK       PRODUCT                REVENUE      W_W_DIFF             PERCENT
---------  -----------------      -------      --------             -------
01-JUL-01  128MB Memory Card        $0.00                               0.0
01-JUL-01  256MB Memory Card    $1,404.15                             100.0
01-JUL-01   64MB Memory Card        $0.00                               0.0
08-JUL-01  128MB Memory Card    $6,567.48     $6,567.48                43.6
08-JUL-01  256MB Memory Card    $8,506.01     $7,101.86                56.4
08-JUL-01   64MB Memory Card        $0.00         $0.00                 0.0
15-JUL-01  128MB Memory Card        $0.00    -$6,567.48                 0.0
15-JUL-01  256MB Memory Card      $138.82    -$8,367.19               100.0
15-JUL-01   64MB Memory Card        $0.00         $0.00                 0.0

第IV部

データ・ウェアハウスの管理

第IV部では、データ・ウェアハウスのメンテナンス方法について説明します。内容は次のとおりです。

- 第8章「データ・ウェアハウスのリフレッシュ」

- 第9章「データ・ウェアハウスの操作の最適化」

- 第10章「パフォーマンス・ボトルネックの排除」

- 第11章「データ・ウェアハウスのバックアップおよびリカバリ」

- 第12章「データ・ウェアハウスのセキュリティ」

8 データ・ウェアハウスのリフレッシュ

データ・ウェアハウスを定期的に更新し、現在の情報を導出します。データの更新プロセスをリフレッシュ処理と呼び、この章では次の内容について説明します。

- データ・ウェアハウスのリフレッシュについて

- ローリング・ウィンドウを使用したデータのオフロード

データ・ウェアハウスのリフレッシュについて

抽出、変換およびロード(ETL)は、スケジュールに基づいて実行され、元のソース・システムへの変更が反映されます。この手順の間、新規の更新されたデータを本番データのウェアハウス・スキーマに物理的に挿入し、ユーザーがこのデータを使用できるようにするために、他のすべての必要な手順(索引の作成、制限の検証、バックアップ・コピーの作成)に従います。このデータをすべてデータ・ウェアハウスにロードしたら、マテリアライズド・ビューを更新して最新のデータを反映する必要があります。

データ・ウェアハウスのパーティショニング・スキームは、データ・ウェアハウスのロード・プロセスでの操作のリフレッシュの効率性を決定する際に重要です。ロード・プロセスは、データ・ウェアハウス表のパーティショニング・スキームの選択時に考慮されます。

多くのデータ・ウェアハウスでは、定期的に新規データがロードされます。たとえば、日、週または月ごとに新規データがデータ・ウェアハウスに取り込まれます。週末または月末にロードされたデータは通常、その週またはその月のトランザクションに対応します。この一般的なシナリオでは、データ・ウェアハウスは時間ごとにロードされます。そのため、データ・ウェアハウス表をデータ列上でパーティション化することをお薦めします。データ・ウェアハウスの例として、新規データが毎月、売上表にロードされると想定します。さらに、sales表は毎月、パーティション化されるものとします。これらの手順では、ロード・プロセスによる新しい月(2006年第1四半期)のsales表へのデータの追加処理方法を示します。

例: データ・ウェアハウスのリフレッシュ

多くの問合せでは、日付で問合せが制限されているproducts、customersおよびsales表の一部の列が要求されます。マテリアライズド・ビューを使用すると、3つの表に対する問合せの多くが高速化されます。上部にマテリアライズド・ビューが作成される事前作成表を使用します。sales表のパーティション計画を持つ同期のマテリアライズド・ビューのパーティション計画を選択します。

次に、マテリアライズド・ビューのリフレッシュに関する例を示します。ここでは、パーティション交換ロード操作を使用します。この例はshスキーマのsales表に基づいています。

マテリアライズド・ビューをリフレッシュする手順

1. マテリアライズド・ビューに基づいた表を作成します。

CREATE TABLE sales_prod_cust_mv
( time_id DATE
, prod_id NUMBER
, prod_name VARCHAR2(50)
, cust_id NUMBER
, cust_first_name VARCHAR2(20)
, cust_last_name VARCHAR2(40)
, amount_sold NUMBER
, quantity_sold NUMBER
)
PARTITION BY RANGE (time_id)
( PARTITION p1999 VALUES LESS THAN (TO_DATE('01-JAN-2000','DD-MON-YYYY'))
, PARTITION p2000 VALUES LESS THAN (TO_DATE('01-JAN-2001','DD-MON-YYYY'))
, PARTITION p2001h1 VALUES LESS THAN (TO_DATE('01-JUL-2001','DD-MON-YYYY'))
, PARTITION p2001h2 VALUES LESS THAN (TO_DATE('01-JAN-2002','DD-MON-YYYY'))
, PARTITION p2001q1 VALUES LESS THAN (TO_DATE('01-APR-2002','DD-MON-YYYY'))
, PARTITION p2002q2 VALUES LESS THAN (TO_DATE('01-JUL-2002','DD-MON-YYYY'))
, PARTITION p2002q3 VALUES LESS THAN (TO_DATE('01-OCT-2002','DD-MON-YYYY'))
, PARTITION p2002q4 VALUES LESS THAN (TO_DATE('01-JAN-2003','DD-MON-YYYY'))
, PARTITION p2003q1 VALUES LESS THAN (TO_DATE('01-APR-2003','DD-MON-YYYY'))
, PARTITION p2003q2 VALUES LESS THAN (TO_DATE('01-JUL-2003','DD-MON-YYYY'))
, PARTITION p2003q3 VALUES LESS THAN (TO_DATE('01-OCT-2003','DD-MON-YYYY'))
, PARTITION p2003q4 VALUES LESS THAN (TO_DATE('01-JAN-2004','DD-MON-YYYY'))
, PARTITION p2004q1 VALUES LESS THAN (TO_DATE('01-APR-2004','DD-MON-YYYY'))
, PARTITION p2004q2 VALUES LESS THAN (TO_DATE('01-JUL-2004','DD-MON-YYYY'))
, PARTITION p2004q3 VALUES LESS THAN (TO_DATE('01-OCT-2004','DD-MON-YYYY'))
, PARTITION p2004q4 VALUES LESS THAN (TO_DATE('01-JAN-2005','DD-MON-YYYY'))
, PARTITION p2005q1 VALUES LESS THAN (TO_DATE('01-APR-2005','DD-MON-YYYY'))
, PARTITION p2005q2 VALUES LESS THAN (TO_DATE('01-JUL-2005','DD-MON-YYYY'))
, PARTITION p2005q3 VALUES LESS THAN (TO_DATE('01-OCT-2005','DD-MON-YYYY'))
, PARTITION p2005q4 VALUES LESS THAN (TO_DATE('01-JAN-2006','DD-MON-YYYY'))
, PARTITION p2006q1 VALUES LESS THAN (TO_DATE('01-APR-2006','DD-MON-YYYY'))
) PARALLEL COMPRESS;

2. sales表の初期表をロードします。

ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+ PARALLEL smv */ INTO sales_prod_cust_mv smv
SELECT /*+ PARALLEL s PARALLEL c */ s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, cust_first_name
, c.cust_last_name
, SUM(s.amount_sold)
, SUM(s.quantity_sold)
FROM sales s
, products p
, customers c
WHERE s.cust_id = c.cust_id
AND s.prod_id = p.prod_id
GROUP BY s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, c.cust_first_name
, c.cust_last_name;
COMMIT;

3. マテリアライズド・ビューを作成します。

CREATE MATERIALIZED VIEW sales_prod_cust_mv
ON PREBUILT TABLE
ENABLE QUERY REWRITE
AS SELECT s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, c.cust_first_name
, c.cust_last_name
, SUM(s.amount_sold) amount_sold
, SUM(s.quantity_sold) quantity_sold
FROM sales s
, products p
, customers c
WHERE s.cust_id = c.cust_id
AND s.prod_id = p.prod_id
GROUP BY s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, c.cust_first_name
, c.cust_last_name;

4. 新規パーティションで交換される個別の表をロードします。

CREATE TABLE sales_q1_2006 PARALLEL COMPRESS
AS SELECT * FROM sales
WHERE 0 = 1;

/* This would be the regular ETL job */

ALTER SESSION ENABLE PARALLEL DML;

INSERT /* PARALLEL qs */ INTO sales_q1_2006 qs
SELECT /* PARALLEL s */ prod_id
, cust_id
, add_months(time_id,3)
, channel_id
, promo_id
, quantity_sold
, amount_sold
FROM sales PARTITION(sales_q4_2005) s;

COMMIT;

CREATE BITMAP INDEX bmp_indx_prod_id ON sales_q1_2006 (prod_id);
CREATE BITMAP INDEX bmp_indx_cust_id ON sales_q1_2006 (cust_id);
CREATE BITMAP INDEX bmp_indx_time_id ON sales_q1_2006 (time_id);
CREATE BITMAP INDEX bmp_indx_channel_id ON sales_q1_2006 (channel_id);
CREATE BITMAP INDEX bmp_indx_promo_id ON sales_q1_2006 (promo_id);

ALTER TABLE sales_q1_2006 ADD CONSTRAINT sales_q_prod_fk
FOREIGN KEY (prod_id) REFERENCES products(prod_id) ENABLE NOVALIDATE;

ALTER TABLE sales_q1_2006 ADD CONSTRAINT sales_q_cust_fk
FOREIGN KEY (cust_id) REFERENCES customers(cust_id) ENABLE NOVALIDATE;

ALTER TABLE sales_q1_2006 ADD CONSTRAINT sales_q_time_fk
FOREIGN KEY (time_id) REFERENCES times(time_id) ENABLE NOVALIDATE;

ALTER table sales_q1_2006 ADD CONSTRAINT sales_q_channel_fk
FOREIGN KEY (channel_id) REFERENCES channels(channel_id) ENABLE NOVALIDATE;

ALTER table sales_q1_2006 ADD CONSTRAINT sales_q_promo_fk
FOREIGN KEY (promo_id) REFERENCES promotions(promo_id) ENABLE NOVALIDATE;

BEGIN
DBMS_STATS.GATHER_TABLE_STATS('SH','SALES_Q1_2006');
END;
/

5. マテリアライズド・ビューのパーティションで交換される個別の表を作成およびロードします。

CREATE TABLE sales_mv_q1_2006 PARALLEL COMPRESS
AS SELECT * FROM sales_prod_cust_mv
WHERE 1 = 0;

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+ PARALLEL smv */ INTO sales_mv_q1_2006 smv
SELECT /*+ PARALLEL s PARALLEL c */ s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, cust_first_name
, c.cust_last_name
, SUM(s.amount_sold)
, SUM(s.quantity_sold)
FROM sales_q1_2006 s
, products p
, customers c
WHERE s.cust_id = c.cust_id
AND s.prod_id = p.prod_id
GROUP BY s.time_id
, s.prod_id
, p.prod_name
, s.cust_id
, c.cust_first_name
, c.cust_last_name;

COMMIT;

6. 統計を収集します。

BEGIN
DBMS_STATS.GATHER_TABLE_STATS('SH','SALES_MV_Q1_2006');
END;

7. パーティションを交換します。

ALTER TABLE sales
EXCHANGE PARTITION sales_q1_2006
WITH TABLE sales_q1_2006
INCLUDING INDEXES WITHOUT VALIDATION;

ALTER TABLE sales_prod_cust_mv
EXCHANGE PARTITION p2006q1
WITH TABLE sales_mv_q1_2006
INCLUDING INDEXES WITHOUT VALIDATION;

8. マテリアライズド・ビューが再度フレッシュになったことがデータベースに通知されます。

ALTER MATERIALIZED VIEW sales_prod_cust_mv CONSIDER FRESH;

このシナリオでは、事前作成表を使用し、この制約はRELY制約ではないため、クエリー・リライト機能はquery_rewrite_integrityパラメータをSTALE_TOLERATEDに設定した場合にのみ有効です。

ローリング・ウィンドウを使用したデータのオフロード

データを削除したりアーカイブする際にローリング・ウィンドウを使用すると特に効果的です。たとえば、最新の36か月の売上データをデータ・ウェアハウスに格納する場合にローリング・ウィンドウを使用します。新規パーティションは、新しい月のsales表にそれぞれ追加され、古いパーティションはsales表から削除される場合があります。この方法では、ウェアハウスに常に36か月分のデータが保持されます。

例: ローリング・ウィンドウの使用

次にshスキーマのsales表のローリング・ウィンドウの例を示します。

ローリング・ウィンドウを使用する手順

1. 2005年12月の売上を追加します。

ALTER TABLE sales
ADD PARTITION sales_12_2005 VALUES LESS THAN ('01-JAN-2006');

既存の索引を再作成する必要があります。

2. 1999年のパーティションを削除します。

ALTER TABLE sales
DROP PARTITION sales_1999;

9 データ・ウェアハウスの操作の最適化

この章では、データ・ウェアハウスのパフォーマンスを最適化する方法を説明します。内容は次のとおりです。

- システムのオーバーロードの回避

- 索引およびマテリアライズド・ビューの使用の最適化

- 記憶域要件の最適化

システムのオーバーロードの回避

この項では、システムのオーバーロードを識別して回避する方法について説明します。一般的に、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』の説明に従って、自動診断機能である自動データベース診断モニター(ADDM)を使用して、データベースでのパフォーマンスの問題を識別する必要があります。この項では、システムにおけるパフォーマンスの問題を回避する別の方法について、次のとおり説明します。

- システム・パフォーマンスの監視

- データベース・リソース・マネージャの使用

システム・パフォーマンスの監視

この項では、重要なメトリックを定期的に監視することによりシステムのオーバーロードを回避する方法の詳細を提供します。Oracle Enterprise Managerの「データベース・パフォーマンス」ページを介してこれらのメトリックを監視できます。この項の内容は次のとおりです。

- パラレル実行パフォーマンスの監視

- I/Oの監視

パラレル実行パフォーマンスの監視

この項では、パラレル実行パフォーマンスを監視する方法を説明します。多くのパラレル文がダウングレードされているとします。これは、パフォーマンスの問題を示します。想定よりも低い並列度で文が実行されると大幅に時間がかかり、文がダウングレードされたかどうかによって実行時間が異なります。パラレル文がダウングレードする原因には次のようなものが考えられます。

- 最初の並列度が高く、低くする必要がある場合。

- 使用可能なパラレル・サーバーが十分になく、システムがオーバーロードしている場合。

パラレル実行を監視する手順

1. データベースのホームページで「パフォーマンス」をクリックします。
「パフォーマンス」ページが表示されます。

2. ページを下へスクロールします。リンクのリストの下で、「PQ」をクリックします。
「PQ」ページが表示されます。次の項目に対してパラレル問合せのパフォーマンス特性が表示されます。

- パラレル・セッション

- パラレル・スレーブ

- DMLおよびDDLのパラレル化

- シリアライズおよび文のダウングレード

図9-1 パラレル実行の監視

「図9-1 パラレル実行の監視」の説明

I/Oの監視

この項では、I/Oパフォーマンスを監視する方法を説明します。システムのスループットがシステム構成に基づいて予想していたものより大幅に低く(第2章「データ・ウェアハウス・システムの設定」を参照)、ユーザーがパフォーマンスに関して不満がある場合は、パフォーマンスに問題があると考えられます。適切に構成されたシステムで通常のデータ・ウェアハウス・ワークロードを処理する場合、単一のI/Oブロックに対して、おおむね良好なI/Oと、比較的短い待ち時間(30ミリ秒以下)を期待できます。

I/Oパフォーマンス監視する手順

1. データベースのホームページで「パフォーマンス」をクリックします。
「パフォーマンス」ページが表示されます。

2. ページを下へスクロールします。リンクのリストの下で、「I/O」をクリックします。
I/Oページが表示され、「ファンクションごとのI/O MB/秒」と「ファンクションごとのI/Oリクエスト数/秒」が表示されます。

3. 読取り/書込み操作に関する詳細は、「I/Oタイプ」を選択します。
次の項目に対してI/O詳細が表示されます。

- 大規模の書込み

- 大規模の読取り

- 小規模の書込み

- 小規模の読取り

図9-2 I/Oの監視

「図9-2 I/Oの監視」の説明

データベース・リソース・マネージャの使用

Database Resource Managerを使用すると、Oracleシステム内の作業に優先順位を設定できます。たとえば、優先度の高いジョブのあるユーザーは、オンライン作業のレスポンス時間を最短に抑えるためにリソースを取得する一方、バッチ・ジョブやレポートなどの優先度の低いジョブのあるユーザーに対しては、レスポンス時間が遅くなります。このように優先度を割り当てることによってリソースをより細かく制御することができ、コンシューマ・グループに対して、コンシューマ・グループの自動切替え、最大アクティブ・セッションの制御、問合せ実行時間の見積り、UNDOプール割当て制限などの機能が提供されます。

各コンシューマ・グループの同時にアクティブなセッションの最大数を指定できます。この制限に到達した場合、データベース・リソース・マネージャにより、すべての後続のリクエストが並べられ、既存のアクティブ・セッションが完了した後にのみそれらが実行されます。

データベース・リソース・マネージャはOracle Databaseの一部で、データベース内部の異なるプロセスを区別できます。結果として、データベース・リソース・マネージャにより、データベース内部で実行されている個別の操作に優先度を割り当てることができます。

データベース・リソース・マネージャを使用して、次のことを実行できます。

- システムにかかる負荷およびユーザー数に関係なく、処理リソースの最低量をユーザーに保証します。

- CPU時間の割合を異なるユーザーおよびアプリケーションに割り当てることにより、使用可能な処理リソースを配分します。データ・ウェアハウスでは、バッチ・ジョブよりもリレーショナル・オンライン分析処理(ROLAP)アプリケーションに対する割当ての方が多くなります。

- 管理者が定義した基準に基づいて、ユーザーを1つのグループから他のグループに自動的に切り替えます。あるユーザー・グループのメンバーが、指定時間より長くかかるセッションを作成した場合、そのセッションはリソース要件の異なる他のユーザー・グループに自動的に切り替えられます。

- 特定のリソース割当て方法を使用するようにインスタンスを構成します。この方法は、インスタンスを停止して再起動する必要なく、日中設定から夜間設定などのように動的に変更できます。

索引およびマテリアライズド・ビューの使用の最適化

索引およびマテリアライズド・ビューを使用することにより、データ・ウェアハウスのパフォーマンスを向上させることができます。SQLアクセス・アドバイザの主な利点は、現行のワークロードを推奨事項の基準として使用できることです。

例: SQLアクセス・アドバイザを使用した索引およびマテリアライズド・ビューの使用の最適化

この例では、特定の索引およびマテリアライズド・ビューを利用しているシステムで実行されているワークロードを所有すると仮定します。

索引およびマテリアライズド・ビューを最適化する手順

1. 「アドバイザ・セントラル」ページから、「SQLアドバイザ」をクリックします。
「アドバイザ」ページが表示されます。

2. 「アドバイザ」ページから、「SQLアクセス・アドバイザ」をクリックします。
「SQLアクセス・アドバイザ」ページが表示されます。

3. 「デフォルト・オプションを使用」を選択して、「続行」をクリックします。
「ワークロード・ソース」ページが表示されます。

4. 「既存のSQLチューニング・セットを使用」をワークロード・ソースとして選択します。SQLチューニング・セットに移動し、「選択」をクリックします。次に、「次へ」をクリックします。
「推奨オプション」ページが表示されます。

5. 「索引」、「マテリアライズド・ビュー」、および「包括モード」を選択します。「次へ」をクリックします。
「スケジュール」ページが表示されます。

6. 「発行」をクリックします。
「推奨」ページが表示されます。

7. 「名前」フィールドに名前を入力し、その開始時間として「即時」を選択します。次に、「次へ」をクリックします。
「確認」ページが表示されます。

8. 「発行」をクリックします。
「確認」ページが表示されます。

9. タスク名を選択し、「結果の表示」をクリックします。
「推奨」、「SQL文」または「詳細」で追加情報を表示できます。

記憶域要件の最適化

データベース・ブロック内の重複値を排除してアーカイブされたデータを圧縮することにより、記憶域要件を削減できます。圧縮可能なデータベース・オブジェクトには、表およびマテリアライズド・ビューが含まれます。パーティション表については、一部またはすべてのパーティションを圧縮できます。圧縮属性は、表領域、表または表のパーティションに対して宣言できます。表領域レベルで宣言された場合、その表領域で作成されたすべての表はデフォルトで圧縮されます。表(またはパーティションまたは表領域)の圧縮属性は変更可能で、その変更はその表に移動する新規データのみに適用されます。この結果、単一の表またはパーティションにはいくつかの圧縮されたブロックといくつかの通常のブロックが含まれます。これにより、圧縮後もデータのサイズが増加しないことが保証されます。圧縮によってブロックのサイズが増加する場合は、圧縮はそのブロックには適用されません。

データ圧縮による記憶域の改善

いくつかのパーティションを圧縮するか、またはパーティション化されたヒープ構成表を作成できます。これを実行するには、完全なパーティション化された表を圧縮対象の表として定義するか、またはパーティション・レベルごとに定義するか、いずれかの定義を行います。特定の宣言のないパーティションは表定義から属性を継承し、表レベルの指定がない場合は表領域定義から継承します。

パーティションを圧縮するかまたは未圧縮のままにするかについての決定は、パーティション化されていない表と同じルールに従います。データを論理的に個別パーティションに区切る場合はレンジ・パーティション化とコンポジット・パーティション化を使用できるので、パーティション表は、主に読取り専用のデータ(パーティション)の圧縮部分として適切な候補です。たとえばこれは、古いデータが使用不可になる前の中間の段階としてのすべてのローリング・ウィンドウ操作に役立ちます。データを圧縮することにより、より多くの古いデータをオンラインで保持でき、追加的な記憶域使用の負荷を最小化できます。

また、既存の未圧縮の表パーティションを後で変更したり、新規の圧縮パーティションおよび未圧縮パーティションを追加したり、MERGE PARTITION、SPLIT PARTITIONまたはMOVE PARTITIONなどのデータ移動が必要なパーティション・メンテナンス操作の一部として圧縮属性を変更できます。パーティションにはデータを含めることができ、または空にすることもできます。

一部または完全に圧縮されたパーティション表のアクセスおよびメンテナンスは、完全に未圧縮のパーティション表と同じです。また、完全に未圧縮のパーティション表に適用されたすべてのルールも、一部または完全に圧縮されたパーティション表に対して有効です。

データ圧縮を使用する手順

次の例では、1つの圧縮パーティション、costs_oldを使用してレンジ・パーティション化された表を作成します。表の圧縮属性および他のすべてのパーティションは表領域レベルから継承されます。

CREATE TABLE costs_demo (
prod_id     NUMBER(6),    time_id     DATE,
unit_cost   NUMBER(10,2), unit_price  NUMBER(10,2))
PARTITION BY RANGE (time_id)
(PARTITION costs_old
VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS,
PARTITION costs_q1_2003
VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
PARTITION costs_q2_2003
VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')),
PARTITION costs_recent VALUES LESS THAN (MAXVALUE));

10 パフォーマンス・ボトルネックの排除

この章では、パフォーマンスの問題を識別して削減する方法を説明します。内容は次のとおりです。

- SQLの効率的な実行の検証

- リソース使用量の最小化によるパフォーマンスの向上

- 最適なリソースの使用

SQLの効率的な実行の検証

システムの正常な実行を保証するには、パフォーマンスの問題を排除することが重要です。この項では、これらのボトルネックを検索して排除する方法について、次のとおり説明します。

- オプティマイザ統計の分析

- 実行計画の分析

- ヒントを使用したデータ・ウェアハウスのパフォーマンスの向上

- アドバイザを使用したSQLパフォーマンスの検証

オプティマイザ統計の分析

オプティマイザ統計は、データベース内のデータベースおよびオブジェクトについてより詳細に説明するデータが収集されたものです。これらの統計はデータ・ディクショナリに格納され、問合せオプティマイザにより使用されて各SQL文に最適な実行計画を選択します。オプティマイザ統計には、次が含まれます。

- 表統計(行数、ブロックおよび平均の行長さ)

- 列統計(列内の固有の値の数、列内のNULL値の数およびデータ配分)

- 索引統計(リーフ・ブロックの数、レベルおよびクラスタリング・ファクタ)

- システム統計(CPUとI/Oのパフォーマンスおよび使用率)

オプティマイザ統計は、データ・ディクショナリに格納されます。オプティマイザ統計は、次に類似するデータ・ディクショナリ・ビューを使用して参照できます。

SELECT * FROM DBA_TAB_STATISTICS;

データベース内のオブジェクトは常に変更されるので、これらのデータベース・オブジェクトを正確に示すために統計を定期的に更新する必要があります。統計は、Oracle Databaseにより自動的に維持されるか、またはDBMS_STATSパッケージを使用して手動でオプティマイザ統計を維持することもできます。

実行計画の分析

SQL文を実行するために、Oracle Databaseでは多数のステップを実行します。これらの各ステップでは、データベースから物理的にデータ行を取得するか、文を発行するユーザー用になんらかの方法でそれらのデータを用意しておきます。Oracle Databaseが文の実行に使用するステップの組合せは、実行計画と呼ばれます。実行計画には、文がアクセスする各表のアクセス・パスおよび適切な結合方法を使用した表の順序(結合順序)が含まれます。

EXPLAIN PLAN文を使用して、オプティマイザがSQL文用に選択した実行計画を調査できます。その文が発行されると、オプティマイザにより実行計画が選択され、計画を説明するデータがデータベース表に挿入されます。EXPLAIN PLAN文を発行してから、出力表を問い合せてください。

EXPLAIN PLAN文を使用する一般的なガイドラインは次のとおりです。

- SQLスクリプトであるUTLXPLAN.SQLを使用して、スキーマ内にあるPLAN_TABLEというサンプルの出力表を作成します。

- SQL文の前にEXPLAIN PLAN FOR句を含めます。

- EXPLAIN PLAN文を発行した後、Oracle Databaseにより提供されたスクリプトの1つまたはパッケージの1つを使用して最新の計画の表の出力を表示します。

- EXPLAIN PLAN出力内の実行順序は、最も右側にインデントされた行から始まります。2つの行が等しくインデントされている場合は、通常、上位の行が最初に実行されます。

例: 実行計画の出力の分析

次の文では、2つのEXPLAIN PLAN文の出力を示し、1つは動的プルーニングを使用し、もう1つは静的プルーニングを使用します。

EXPLAIN PLANの出力を分析する手順

EXPLAIN PLAN FOR
SELECT p.prod_name
, c.channel_desc
, SUM(s.amount_sold) revenue
FROM products p
, channels c
, sales s
WHERE s.prod_id = p.prod_id
AND s.channel_id = c.channel_id
AND s.time_id BETWEEN '01-12-2001' AND '31-12-2001'
GROUP BY p.prod_name
, c.channel_desc;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

WITHOUT TO_DATE
---------------------------------------------------------------------------------------------------
| Id| Operation                              |      Name    |Rows|Bytes|Cost  | Time |Pstart|Pstop|
(%CPU)
---------------------------------------------------------------------------------------------------
|  0|SELECT STATEMENT                        |              | 252|15876|305(1)|00:00:06|    |     |
|  1| HASH GROUP BY                          |              | 252|15876|305(1)|00:00:06|    |     |
| *2|  FILTER                                |              |    |     |      |        |    |     |
| *3|   HASH JOIN                            |              |2255| 138K|304(1)|00:00:06|    |     |
|  4|    TABLE ACCESS FULL                   |     PRODUCTS |  72| 2160|  2(0)|00:00:01|    |     |
|  5|    MERGE JOIN                          |              |2286|75438|302(1)|00:00:06|    |     |
|  6|     TABLE ACCESS BY INDEX ROWID        |     CHANNELS |   5|   65|  2(0)|00:00:01|    |     |
|  7|      INDEX FULL SCAN                   |  CHANNELS_PK |   5|     |  1(0)|00:00:01|    |     |
| *8|     SORT JOIN                          |              |2286|45720|299(1)|00:00:06|    |     |
|  9|      PARTITION RANGE ITERATOR          |              |2286|45720|298(0)|00:00:06| KEY|  KEY|
| 10|       TABLE ACCESS BY LOCAL INDEX ROWID|        SALES |2286|45720|298(0)|00:00:06| KEY|  KEY|
| 11|        BITMAP CONVERSION TO ROWIDS     |              |    |     |      |        |    |     |
|*12|         BITMAP INDEX RANGE SCAN        |SALES_TIME_BIX|    |     |      |        | KEY|  KEY|
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter(TO_DATE('01-12-2001')<=TO_DATE('31-12-2001'))
3 - access("S"."PROD_ID"="P"."PROD_ID")
8 - access("S"."CHANNEL_ID"="C"."CHANNEL_ID")
filter("S"."CHANNEL_ID"="C"."CHANNEL_ID")
12 - access("S"."TIME_ID">='01-12-2001' AND "S"."TIME_ID"<='31-12-2001')
Note the values of KEY KEY for Pstart and Pstop.

WITH TO_DATE
--------------------------------------------------------------------------------------------------
|Id| Operation                 | Name   | Rows  | Bytes |Cost(%CPU)| Time     | Pstart| Pstop |
--------------------------------------------------------------------------------------------------
| 0| SELECT STATEMENT          |        |   252 | 15876 |   31 (20)| 00:00:01 |       |       |
| 1|  HASH GROUP BY            |        |   252 | 15876 |   31 (20)| 00:00:01 |       |       |
|*2|   HASH JOIN               |        | 21717 |  1336K|   28 (11)| 00:00:01 |       |       |
| 3|    TABLE ACCESS FULL      |PRODUCTS|    72 |  2160 |    2  (0)| 00:00:01 |       |       |
|*4|    HASH JOIN              |        | 21717 |   699K|   26 (12)| 00:00:01 |       |       |
| 5|     TABLE ACCESS FULL     |CHANNELS|     5 |    65 |    3  (0)| 00:00:01 |       |       |
| 6|     PARTITION RANGE SINGLE|        | 21717 |   424K|   22 (10)| 00:00:01 |    20 |    20 |
|*7|      TABLE ACCESS FULL    |SALES   | 21717 |   424K|   22 (10)| 00:00:01 |    20 |    20 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("S"."PROD_ID"="P"."PROD_ID")
4 - access("S"."CHANNEL_ID"="C"."CHANNEL_ID")
7 - filter("S"."TIME_ID">=TO_DATE('2001-12-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"S"."TIME_ID"<=TO_DATE('2001-12-31 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
Note the values of 20 20 for Pstart and Pstop.

最初の実行計画は、PstartおよびPstopそれぞれのKEY値を使用して動的プルーニングを表示します。動的プルーニングは、アクセスするパーティションをデータベースで決定する処理を実行時に行う必要があることを意味します。静的プルーニングでは、アクセスするパーティションを解析時に把握できるため、より効果的な実行が可能になります。

明示的な日付変換を使用して実行計画を頻繁に改善できます。明示的な日付変換の使用は、最適なパーティション・プルーニングおよび索引の使用のためのベスト・プラクティスです。

ヒントを使用したデータ・ウェアハウスのパフォーマンスの向上

ヒントによって、通常はオプティマイザによって行われる決定を行うことができます。アプリケーション開発者は、オプティマイザが把握していないデータ情報を持っていることがあります。ヒントによってメカニズムが提供され、特定の基準に基づく問合せ実行プランを選択するためにオプティマイザに通知されます。

たとえば、ユーザーが、特定の問合せに対して特定の索引が選択可能であることを把握している場合があります。この情報に基づいて、オプティマイザが選択するより効率的な実行計画を選択できる場合があります。このような場合は、ヒントを使用して、最適な実行計画を使用するようにオプティマイザに指示します。

デフォルトでは、Oracle Warehouse Builderには、一般的なデータ・ロードを最適化するヒントが含まれます。

参照:
『Oracle Warehouse Builderソースおよびターゲット・ガイド』

例: ヒントを使用したデータ・ウェアハウスのパフォーマンスの向上

システムがアイドル状態である間に昨年の売上表のサマリーを迅速に実行することを想定します。この場合は、次の文を発行できます。

データ・ウェアハウスのパフォーマンスを向上させるためにヒントを使用する手順

SELECT /*+ PARALLEL(s,16) */ SUM(amount_sold)
FROM sales s
WHERE s.time_id BETWEEN TO_DATE('01-JAN-2005','DD-MON-YYYY')
AND TO_DATE('31-DEC-2005','DD-MON-YYYY');

データ・ウェアハウスでヒントを使用するもう1つの一般的な方法は、圧縮の使用によるレコードの効率的なロードを保証することです。次のSQLに示すように、APPENDヒントを使用します。

...
INSERT /* +APPEND */ INTO my_materialized_view
...

アドバイザを使用したSQLパフォーマンスの検証

SQLチューニング・アドバイザおよびSQLアクセス・アドバイザを使用すると、問合せオプティマイザをアドバイス・モードで起動して1つまたは一連のSQL文を調べ、SQL文の効率を改善する推奨事項を提示できます。SQLチューニング・アドバイザおよびSQLアクセス・アドバイザはSQLプロファイルの作成、SQL文の再構築、付加的な索引またはマテリアライズド・ビューの作成、およびオプティマイザ統計のリフレッシュなどの様々なタイプの推奨事項を作成できます。さらに、Oracle Enterprise Managerを使用すると、数回のマウス・クリックでこれらの推奨事項を受け入れ、実装できます。

SQLアクセス・アドバイザは、主に索引およびマテリアライズド・ビューの追加および削除などのスキーマ変更の推奨事項を作成する場合に使用します。また、パーティション計画も推奨します。SQLチューニング・アドバイザは、SQLプロファイルの作成、SQL文の再構築などの他のタイプの推奨事項の作成に使用します。新しい索引を作成してパフォーマンスが大幅に向上できる場合、SQLチューニング・アドバイザは索引の作成を推奨する可能性があります。ただし、これらの推奨事項は、典型的なSQL文のセットを含んだSQLワークロードを使用してSQLアクセス・アドバイザを実行し、検証する必要があります。

例: SQLチューニング・アドバイザを使用したSQLパフォーマンスの検証

SQLチューニング・アドバイザを使用して、単一または複数のSQL文をチューニングできます。複数のSQL文をチューニングする場合、SQLチューニング・アドバイザはSQL文間の相互依存を認識しないことに注意してください。かわりに、多数のSQL文に対してSQLチューニング・アドバイザを実行すると有効です。

SQLチューニング・アドバイザを実行してSQLパフォーマンスを検証する手順は、次のとおりです。

1. 「セントラル・アドバイザ」ページに移動して、「SQLアドバイザ」をクリックします。
「SQLアドバイザ」ページが表示されます。

2. 「SQLチューニング・アドバイザのスケジュール」をクリックします。
「SQLチューニング・アドバイザのスケジュール」ページが表示されます。推奨される名前は「名前」フィールドに表示され、変更が可能です。その後「包括」を選択して実行する包括的な分析を取得します。「スケジュール」の「即時」を選択します。適切なSQLチューニング・セットを選択した後、「OK」をクリックします。

3. 「処理中」ページが表示されます。その後、「推奨」ページにパフォーマンス向上の推奨事項が表示されます。「推奨の表示」をクリックします。
「推奨」ページが表示されます。

4. 推奨事項は、「実装」をクリックして実装できる索引を作成することです。SQLアクセス・アドバイザを実行することもできます。

リソース使用量の最小化によるパフォーマンスの向上

次の機能を使用して、リソースの使用量を最小化し、データ・ウェアハウスのパフォーマンスを向上させることができます。

- パフォーマンスの向上: パーティション化

- パフォーマンスの向上: クエリー・リライトおよびマテリアライズド・ビュー

- パフォーマンスの向上: 索引

- パフォーマンスの向上: 圧縮

パフォーマンスの向上: パーティション化

データ・ウェアハウスにはサイズの大きな表が含まれていることが多く、これらのサイズの大きな表を管理する技術およびこれらの表全体に良質な問合せのパフォーマンスを提供する技術の両方が必要になります。この項では、パーティション化とこれらの要件に対処するための主要な方法を説明します。データ・ウェアハウスの問合せのパフォーマンスに関連する2つの機能は、パーティション・プルーニングとパーティションワイズ結合です。

パフォーマンスの向上: パーティション・プルーニング

パーティション・プルーニングは、データ・ウェアハウスに必須のパフォーマンス機能です。パーティション・プルーニングでは、オプティマイザによりSQL文のFROM句およびWHERE句が分析され、パーティション・アクセス・リストの作成時に不必要なパーティションが排除されます。これにより、Oracle Databaseを使用してSQL文に関連するパーティションでのみ操作を実行できます。レンジ・パーティション化列またはリスト・パーティション化列にある範囲述語、LIKE述語、等価述語およびIN-リスト述語を使用する場合とハッシュ・パーティション化列にある等価述語およびIN-リストを使用する場合は、Oracle Databaseによりパーティションがプルーニングされます。

パーティション・プルーニングを実行すると、ディスクから取得するデータ量が大幅に削減され、処理時間の使用が短縮されるため、問合せのパフォーマンスとリソースの使用量が改善されます。グローバルなパーティション索引を使用して異なる列の索引および表をパーティション化する場合は、基礎となる表が排除できない場合でもパーティション・プルーニングにより索引パーティションが排除されます。

実際のSQL文に応じて、Oracle Databaseにより静的プルーニングおよび動的プルーニングが使用されます。静的プルーニングはコンパイル時に発生し、パーティションに関する情報が事前にアクセスされる一方で、動的プルーニングは実行時に発生し、文のアクセス対象となるパーティションは事前に把握できません。静的プルーニングのサンプルの使用例は、パーティション・キー列に固定リテラルがあるWHERE句を含むSQL文です。動的プルーニングの例は、WHERE句内の演算子または関数の使用です。

パーティション・プルーニングは、プルーニングが発生するオブジェクトの統計に影響し、文の実行計画にも影響します。

パフォーマンスの向上: パーティションワイズ結合

パーティションワイズ結合では、結合がパラレルで実行されるときにパラレル実行サーバー間で交換されるデータ量が最小限に抑えられ、問合せのレスポンス時間が短縮されます。レスポンス時間は大幅に短縮され、CPUとメモリー・リソースの使用率が改善されます。また、Oracle Real Application Clusters環境では、パーティションワイズ結合によって相互接続のデータ通信を回避するか、少なくとも制限することができ、これは大規模な結合操作に対する良質なスケーラビリティを実現するために重要です。

パーティションワイズ結合では、全体的または部分的です。Oracle Databaseにより使用する結合のタイプが決定されます。

例: SQLアクセス・アドバイザを使用したパーティション化の評価

データ・ウェアハウス環境では、常にパーティション化を考慮する必要があります。

パーティション化を評価する手順

1. 「アドバイザ・セントラル」ページで、「SQLアドバイザ」をクリックします。
「SQLアドバイザ」ページが表示されます。

2. 「SQLアクセス・アドバイザ」をクリックします。
「SQLアクセス・アドバイザ」ページが表示されます。

3. 「初期オプション」メニューから、「デフォルト・オプションを使用」を選択し、「続行」をクリックします。

4. 「ワークロード・ソース」から、「現在と最近のSQLアクティビティ」を選択し、「次へ」をクリックします。
「推奨オプション」ページが表示されます。

5. 「パーティション化」を選択し、次に「包括モード」を選択して、「次へ」をクリックします。
「スケジュール」ページが表示されます。

6. 「タスク名」フィールドにSQLACCESStest1を入力し、「次へ」をクリックします。
「確認」ページが表示されます。「発行」をクリックします。

7. 「発行」をクリックします。
「確認」ページが表示されます。

8. タスクを選択し、「結果の表示」をクリックします。「タスクの結果」ページが表示され、パーティション化の結果として可能な向上が示されます。

図10-1 パーティション化の結果

「図10-1 パーティション化の結果」の説明

パフォーマンスの向上: クエリー・リライトおよびマテリアライズド・ビュー

データ・ウェアハウスでは、マテリアライズド・ビューを使用して売上の合計などの集計データを計算して格納できます。また、マテリアライズド・ビューを使用して集計を加えたり除いたりすることによって結合を計算でき、コストの高い計算と同様、頻繁に実行されるサイズの大きな表間のコストの高い結合にも便利です。マテリアライズド・ビューにより、大規模な結合または問合せを処理する前にサマリーが作成されたデータを計算して格納するので、大規模または重要なクラスの問合せのためのコストの高い結合および集計に関連付けられたオーバーヘッドは排除されます。これらの環境でマテリアライズド・ビューは多くの場合、サマリーと呼ばれます。

マテリアライズド・ビューを作成して保持する主な利点の1つは、表またはビューで表されるSQL文を、詳細表で定義される1つ以上のマテリアライズド・ビューにアクセスする文に変換するクエリー・リライト機能を利用できることです。変換はユーザーおよびアプリケーションに対して透過的で、SQL文内のマテリアライズド・ビューを使用したり参照する必要はありません。クエリー・リライト機能は透過的なので、索引と同様にアプリケーション・コード内のSQLを無効にすることなく、マテリアライズド・ビューを追加または削除できます。

基礎となる表に大量のデータが含まれる場合、必要な集計の計算またはこれらの表間の結合の計算は、リソースの消費が多く、時間がかかる処理になります。このような場合、問合せにより応答が返されるまで数分または数時間かかります。マテリアライズド・ビューにはすでに計算された集計と結合が含まれているので、Oracle Databaseによって強力なクエリー・リライト・プロセスが使用され、マテリアライズド・ビューを使用した問合せに迅速に応答します。

パフォーマンスの向上: 索引

ビットマップ索引はデータ・ウェアハウス環境において広く使用されています。データ・ウェアハウス環境では通常、大量のデータおよび非定型問合せがありますが、DMLトランザクションが同時に発生することは稀です。索引が表内のデータのサイズの数倍である場合があるため、サイズの大きな表に従来のBツリーを完全に索引付けすると、ディスク領域に関してコストが非常に高くなる可能性があります。ビットマップ索引は通常、表内の索引付けされたデータのサイズのほんの一部にすぎません。このようなアプリケーションの場合、ビットマップ索引には次のような特性があります。

- 大規模な非定型問合せに対するレスポンス時間の削減

- 他の索引の方法と比較した場合の記憶域要件の減少

- 比較的CPUの数が少ないハードウェアまたはメモリー量が少ないハードウェア上での大幅なパフォーマンスの向上

- パラレルDMLおよびロード中の効率的なメンテナンス

パフォーマンスの向上: 圧縮

Oracle Databaseでは、バルク・ロード操作時に、ロード中のデータが圧縮されます。データ変換および圧縮は内部的に処理され、圧縮を使用するためにアプリケーションを変更する必要はありません。圧縮によって、データのスキャンに必要なI/Oの量が削減されるため、大容量のデータをスキャンする問合せのパフォーマンスが向上します。

この機能を構成するために特にインストールが必要なものはありません。ただし、この機能を使用するには、データベース互換パラメータを11.2.0以上に設定する必要があります。

注意:
Hybrid Columnar圧縮は、特定のOracleストレージ・システムが持つ機能です。詳細は、『Oracle Database概要』を参照してください。

パフォーマンスの向上: DBMS_COMPRESSIONパッケージ

PL/SQLパッケージDBMS_COMPRESSIONには、アプリケーションに対して適切な圧縮レベルを選択するための圧縮アドバイザ・インタフェースがあります。圧縮アドバイザは、データベース内のオブジェクトを分析し、達成可能な圧縮率を見積ります。

参照:

- DBMS_COMPRESSIONパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

パフォーマンスの向上: CREATE TABLEおよびALTER TABLEのtable_compress句

CREATE TABLEおよびALTER TABLE文のtable_compress句で提供されるCOMPRESSは、圧縮レベルのパラメータを取ります。COMPRESSを使用して、データ・セグメントを圧縮してディスク使用量を削減するかどうかをデータベースに指示します。すべての形式の表圧縮は、通常、挿入操作および更新操作の回数が少ないOLAP環境およびデータ・ウェアハウスで役立ちますが、一部の形式はOLTP環境でも役立ちます。

注意:
表で圧縮を有効にするには、表の作成時に有効にするか、または表を変更して有効にする必要があります。

参照:
『Oracle Database SQL言語リファレンス』

最適なリソースの使用

可能な場合にパラレルで操作を実行すると、システムでのリソースの使用を最大化できます。リソースによる制限がなければ、データベース操作をより速く実行できます。操作はCPUリソース、I/O容量、メモリーまたは(クラスタ内の)相互接続のトラフィックによって制限される場合があります。データベース操作のパフォーマンスを向上させるには、パフォーマンスの問題に焦点を当て、その問題を排除する必要があります(問題が他のリソースに移行する可能性を考慮し、排除する必要があります)。Oracle Databaseには、使用可能なリソースの使用を最適化し、不必要なリソースを使用しないようにする機能が用意されています。

パラレル実行でのパフォーマンスの最適化

パラレル実行を使用すると、通常ディシジョン・サポート・システム(DSS)およびデータ・ウェアハウスに関連付けられているサイズの大きなデータベース上で、データ集中型の操作のレスポンス時間を大幅に削減できます。また、特定のタイプのオンライン・トランザクション処理(OLTP)およびハイブリッド・システム上で、パラレル実行の実装もできます。パラレル実行はパラレル化とも呼ばれます。パラレル化とは、1つの問合せに関するすべての処理を1つのプロセスで実行するのではなく、複数のプロセスが作業の部分部分を同時に実行できるように、作業を分割することです。たとえば、1年間ですべての四半期を1つのプロセスで処理せずに、四半期それぞれを4つのプロセスで処理します。これを使用するとパフォーマンスの大幅な向上が見込めます。パラレル実行では、次のプロセスを向上できます。

- サイズの大きな表のスキャン、結合またはパーティション化された索引のスキャンを要求する問合せ

- 大規模な索引の作成

- サイズの大きな表の作成(マテリアライズド・ビューを含む)

- 大量データの挿入、更新、マージおよび操作の削除

また、パラレル実行を使用して、Oracle Database内のオブジェクト型にアクセスできます。たとえば、パラレル実行により、ラージ・オブジェクト(LOB)にアクセスできます。

パラレル実行は、次のすべての特性を持つシステム上で有効です。

- 対称型マルチプロセッサ(SMP)、クラスタ、または大規模なパラレル・システム

- 十分なI/O帯域幅

- 稼働中でないCPUまたは断続的に使用されているCPU(CPUの使用率が通常30%未満のシステムなど)

- ソート、ハッシュおよびI/Oバッファなどの追加のメモリー集中処理をサポートする十分なメモリー

これらの特性を持たないシステムでは、パラレル実行を使用しても大幅にパフォーマンスが向上しない場合があります。実際に、大容量を使用しているシステムまたはI/O帯域幅の少ないシステム上では、システムのパフォーマンスが低下する可能性があります。

パラレル実行の動作方法

パラレル実行では、SQL文の実行タスクが複数の小さな単位に分割され、各ユニットは個別のプロセスで実行されます。また、受信するデータ(表、索引、パーティション)もグラニュルと呼ばれる単位に分類されます。ユーザー・シャドウ・プロセスは、パラレル実行のコーディネータまたは問合せコーディネータとしての役割を持ちます。問合せコーディネータは次のタスクを実行します。

- 問合せの解析および並列度の判別

- 1セットまたは2セットのスレーブ(スレッドまたはプロセス)の割当て

- 問合せの制御およびパラレル問合せスレーブへの手順の送信

- パラレル問合せスレーブによるスキャンが必要な表または索引の判別

- ユーザーに対する最終的な出力の作成

並列度の設定

パラレル実行コーディネータでは、2つ以上のインスタンスのパラレル実行サーバーでSQL文を処理する場合があります。単一の操作に関連付けられているパラレル実行サーバーの数は、並列度(DOP)と呼ばれます。

単一の操作は、ORDER BY操作または索引なしの列表に対して結合を実行する全表スキャンなどのSQL文の一部です。

並列度を指定する方法は次のとおりです。

- PARALLELヒントを持つ文レベルでの指定

- ALTER SESSION FORCE PARALLEL文を発行してセッション・レベルでの指定

- 表の定義内で表レベルでの指定

- 索引の定義内で索引レベルでの指定

例: 並列度の設定

表でDOPを4に設定する場合を想定します。

並列度を設定する手順

次の文を発行します。

ALTER TABLE orders PARALLEL 4;

待機イベントについて

待機 イベントはサーバー・プロセスによって増分した統計で、サーバー・プロセスは、イベントが完了し、処理の続行が可能となるまで待機する必要があることを示します。セッションの待機理由は様々で、大量の入力に対する待機、ディスクへの書込み操作などのサービスを完了するためのオペレーティング・システムに対する待機、またはロックやラッチを待機する時間が含まれます。

各セッションがリソースを待機する間、有効な動作は実行されません。待機イベントの多くが問題の原因となります。待機イベント・データにより、ラッチ競合、バッファ競合およびI/O競合などのパフォーマンスに影響を与える可能性のある問題の症状が明らかになります。

11 データ・ウェアハウスのバックアップおよびリカバリ

この章で説明する、データ・ウェアハウスのバックアップおよびリカバリに関する考慮事項には、次の内容が含まれます。

- データ・ウェアハウスのバックアップおよびリカバリの処理方法

- バックアップおよびリカバリの計画とベスト・プラクティス

データ・ウェアハウスのバックアップおよびリカバリの処理方法

バックアップおよびリカバリは、管理者にとって最も重要なタスクであり、データ・ウェアハウスについても同様のことが言えます。ただし、データ・ウェアハウスはデータベースのサイズが大きいため、管理者にとってはバックアップおよびリカバリに関する新たな課題が浮上することになります。

データ・ウェアハウスは、無数のリソースからデータが取得されるという点において特徴的で、データベースに挿入される前に変換されますが、これは主にデータ・ウェアハウスが非常に大規模になるためです。大規模なデータ・ウェアハウスのリカバリ管理は大変なタスクで、従来のOLTPのバックアップ計画およびリカバリ計画では、データ・ウェアハウスの要件を満たさない場合があります。

データ・ウェアハウスとOLTPシステムの相違点は次のとおりです。

- 通常、データ・ウェアハウスのサイズははるかに大規模です。

- データ・ウェアハウスは、運用システムとは異なる可用性の要件を備えています。ビジネスにおける決断でも、データ・ウェアハウスからの情報に依存し、たとえばサービス・デスクが操作できないような状況では、事態はさらに悪化します。また、データ・ウェアハウスのサイズのため、一定水準のデータ・ウェアハウスの可用性を保証するには非常に高いコストがかかります。

- データ・ウェアハウスは、通常、抽出、変換およびロード(ETL)と呼ばれるより優れた制御のプロセスを介して移入されます。この結果、データ・ウェアハウス内の更新は正確に把握され、データ・ソースからの再生成が可能です。

- データ・ウェアハウスには、一般的に、大抵の場合は変更されることがない履歴データが多く格納されます。変更されないデータは、1回のみバックアップする必要があります。

システム設計の一部としてバックアップ計画を計画し、バックアップする対象およびバックアップする頻度を考慮する必要があります。バックアップ設計で最も重要な変数は、バックアップまたはリカバリの実行に使用可能なリソースの量とリカバリ時間目標(システム全体またはシステムの一部の使用不可能な状態の許容時間)です。

バックアップおよびリカバリ計画を計画する場合は、NOLOGGING操作を考慮する必要があります。バックアップをリストアしてアーカイブ・ログから変更を適用する従来のリカバリは、NOLOGGING操作に適用されません。NOLOGGING操作により操作されたデータに依存する操作は失敗します。バックアップおよびリカバリ計画を設計する場合は、NOLOGGING操作を考慮する必要があります。

NOLOGGING操作が行われている場合は、バックアップを作成することはありません。

次の2つの計画のうち1つを計画するか、または2つの計画の組合せを計画します。

- ETL計画
リカバリできないトランザクションを含まないバックアップをリカバリし、バックアップと失敗の間で行われたETLをリプレイします。

- 増分バックアップ計画
その他のリカバリできないトランザクションが行われた後、すぐにバックアップを実行します。変更済データ・ブロックに基づいた増分バックアップを有効にするトラッキング・ファイル機能が提供されます。RMANによりトラッキング・ファイル機能が利用されます。

バックアップおよびリカバリの計画とベスト・プラクティス

バックアップおよびリカバリ計画を考案することは、大変なタスクです。数百GBの保護対象のデータを所有していて失敗した場合にリカバリが必要である場合は、計画は非常に複雑になります。

次のベスト・プラクティスにより、ウェアハウスのバックアップおよびリカバリ計画の実装をサポートします。

- ベスト・プラクティスA: ARCHIVELOGモードの使用

- ベスト・プラクティスB: RMANの使用

- ベスト・プラクティスC: 読取り専用の表領域の使用

- ベスト・プラクティスD: NOLOGGING操作の計画

- ベスト・プラクティスE: すべての表領域の重要度が同等でない場合

ベスト・プラクティスA: ARCHIVELOGモードの使用

アーカイブREDOログは、データベースへの変更の記録であるため、データを失うことがまったく許されない場合のリカバリに非常に重要です。Oracle Databaseは、次の2つのモードのいずれかで実行できます。

- ARCHIVELOG: Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされます。

- NOARCHIVELOG: Oracle Databaseでは、再利用される前に満杯になったオンラインのREDOログ・ファイルがアーカイブされません。

ARCHIVELOGモードでデータベースを実行すると、次の利点があります。

- データベースはインスタンス障害およびメディア障害の両方から完全にリカバリされます。

- データベースを開いて使用可能な状態で、ユーザーはバックアップを実行できます。

- Oracle Databaseにより、多重化されたアーカイブ・ログによるそのアーカイブ・ログ上の単一点障害の回避がサポートされます。

- ユーザーは、表領域のPoint-in-Timeリカバリ(TSPITR)の実行機能のようなより多くのリカバリ・オプションを使用できます。

- アーカイブREDOログは、プライマリ・データベースのコピーであるフィジカル・スタンバイ・データベースに転送および適用できます。

- データベースはインスタンス障害およびメディア障害の両方から完全にリカバリされます。

NOARCHIVELOGモードでデータベースを実行すると、次の結果が得られます。

- 停止後、データベースが完全に閉じられた状態で、ユーザーはデータベースのバックアップのみ実行できます。

- 最後のバックアップ後はすべてのトランザクションの損失の原因となるため、通常、メディア・リカバリ・オプションのみがデータベース全体をリストアします。

停止時間の許容について

データベースが開いている間、または閉じている間でもOracle Databaseのバックアップは作成できます。データベースの計画停止時間は業務を混乱させ、特に複数のタイムゾーンにいるユーザーを最長24時間サポートする世界規模の企業では顕著です。このような場合は、データベースへの割込みを最小化するようにバックアップ計画を設計することが重要です。

業種によっては、停止時間に余裕がある企業もあります。ビジネス計画全体で、停止時間は最小限またはまったくない状態が必要とされる場合は、バックアップ計画にオンライン・バックアップを実装する必要があります。データベースは、バックアップのために停止する必要がありません。オンライン・バックアップでは、データベースをARCHIVELOGモードにする必要があります。

ARCHIVELOGモードを使用しない理由はありません。データ・ウェアハウス(および極めて重要なデータベース)では、ARCHIVELOGモードを使用してください。データ・ウェアハウスのサイズ(およびデータ・ウェアハウスのバックアップにかかる時間)を考慮すると、データ・ウェアハウスのオフライン・バックアップは現実的ではありません(NOARCHIVELOGモードを使用する場合は、そのオフライン・バックアップが必要になります)。

大規模なデータ・ウェアハウスでは、大量のデータ変更によって大量のログ・ファイルが生成される可能性があります。この数多くのアーカイブ・ログ・ファイルを管理できるようにするため、RMANには、アーカイブ時にログ・ファイルを圧縮するオプションがあります。アーカイブ処理により、より多くのアーカイブ・ログをディスク上に保存し、リカバリ時に高速にアクセスできるようになります。

要約すると、ベスト・プラクティスは、データベースをARCHIVELOGモードにしてオンライン・バックアップのオプションとPoint-in-Timeリカバリのオプションを使用可能にすることです。

ベスト・プラクティスB: RMANの使用

Recovery Manager(RMAN)を採用する理由は多数あります。RMANをバックアップおよびリカバリ計画に統合する理由のいくつかは、次の項目が提供されるからです。

- 拡張性の高いレポート

- 増分バックアップ

- 停止時間のないバックアップ

- バックアップおよびリストアの検証

- バックアップおよびリストアの最適化

- メディア・マネージャとの簡単な統合

- ブロック・メディア・リカバリ

- アーカイブ・ログの検証および管理

- 破損ブロックの検出

ベスト・プラクティスC: 読取り専用の表領域の使用

データ・ウェアハウスが直面する最大の問題の1つは、一般的なデータ・ウェアハウスの規模です。強力なバックアップのハードウェアを使用しても、バックアップに数時間かかります。したがって、バックアップするデータの量の最小化を考慮することは、バックアップのパフォーマンスの向上のために重要なことの1つです。読取り専用の表領域は、データ・ウェアハウス内にバックアップするデータの量を削減するための最も簡単なメカニズムです。

読取り専用の表領域の利点は、データのバックアップが1回である点です。データ・ウェアハウスに5年間の履歴データが含まれる場合は、データの最初の4年間は読取り専用にできます。理論上は、データベースの通常のバックアップでデータの20%のみがバックアップされます。これにより、データ・ウェアハウスのバックアップに必要な時間を大幅に短縮できます。

ほとんどのデータ・ウェアハウスでは、時間でレンジ・パーティション化された表にデータが格納されます。通常のデータ・ウェアハウスでは、30日間から1年間までの範囲の期間で、データがアクティブです。この期間中は、履歴データを更新でき、また変更できます(たとえば、小売業者が購入日後の30日間までは返品を受け入れる場合は、売上データの記録をこの期間中に変更できます)。ただし、データが特定の日に到達すると、そのデータは静的であるとみなされます。

パーティション化を利用すると、ユーザーは読取り専用のデータの静的な部分を作成できます。RMANにより、読取り専用のパーティションまたは表ではなく、読取り専用の表領域がサポートされます。読取り専用の表領域を利用してバックアップ・ウィンドウを削減するには、読取り専用の表領域の定数データ・パーティションの格納計画を考案する必要があります。ローリング・ウィンドウを実装する2つの計画は次のとおりです。

- データが静的とみなされるようになった時点で、読取り/書込み表領域から読取り専用表領域にパーティションを移動するための、定期的に実行するプロセスを実装します。
この場合のベスト・プラクティスは、データベースをARCHIVELOGモードにしてオンライン・バックアップおよびPoint-in-Timeリカバリのオプションを使用可能にすることです。

- 各表領域に少数のパーティションを持つ一連の表領域を作成し、その表領域内のデータが年数を重ねるにつれて定期的に1つの表領域を読取り/書込み両用から読取り専用に変更します。
1つ考慮する必要があるのは、データのバックアップはリカバリ・プロセスの半分にすぎないということです。テープのシステムを構成する場合、4時間でデータ・ウェアハウスの読取り/書込み両用の部分をバックアップでき、データベースの80%が読取り専用であるときに完全なリカバリが必要な場合は、必然的にテープのシステムではデータベースをリカバリするために20時間かかります。

要約すると、ベスト・プラクティスは、静的表および静的パーティションを読取り専用の表領域に配置することです。読取り専用の表領域は1回バックアップされます。

ベスト・プラクティスD: NOLOGGING操作の計画

一般的に、データ・ウェアハウスの最優先事項はパフォーマンスです。データ・ウェアハウスにより、オンラインのユーザーに快適な問合せのパフォーマンスが提供される必要があるだけでなく、大量のデータを最短時間内にロードするために、ETLプロセス中、データ・ウェアハウスは効率的である必要があります。

データ・ウェアハウスにより利用される共通の最適化の1つは、NOLOGGINGモードを使用して大量データ操作を実行することです。NOLOGGINGモードをサポートするデータベース操作は、直接パス・ロードおよび直接パス・インサート、索引の作成および表の作成です。1つの操作がNOLOGGINGモードで実行される場合は、データはREDOログに書き込まれません(より正確に言うと、サイズの小さいメタデータのセットのみREDOログに書き込まれます)。このモードは、データ・ウェアハウスの広範囲で使用され、大量データ操作のパフォーマンスを50%まで改善できます。

ただし、リカバリをサポートするために必要なデータがログ・ファイルに書き込まれることはないので、従来のバックアップ・メカニズムを使用してNOLOGGING操作をリカバリすることはできなくなります。さらに、NOLOGGING操作が発生したデータに対する後続の操作は、たとえその操作がNOLOGGINGモードを使用していなかったとしてもリカバリされません。NOLOGGING操作により提供されるパフォーマンスの向上のため、データ・ウェアハウスでは、一般的にETLプロセスでNOLOGGINGモードを使用することをお薦めします。

バックアップおよびリカバリ計画を考案する場合は、NOLOGGING操作の存在を考慮する必要があります。データベースがNOLOGGING操作に依存する場合、ログ・ファイルによりNOLOGGING操作はリカバリできないので、最新のテープ・バックアップからリカバリして、アーカイブ・ログ・ファイルを適用する従来のリカバリ計画は適用できなくなります。

NOLOGGING操作が行われているときは、バックアップを行わないでください。このルールは、今のところ強制的には適用されないため、NOLOGGING操作とバックアップ操作が重ならないように、バックアップ・ジョブとETLジョブをスケジュールする必要があります。

NOLOGGING操作が存在するバックアップおよびリカバリには、2つのアプローチがあります。ETLバックアップまたは増分バックアップです。データ・ウェアハウス内でNOLOGGING操作を使用していない場合は、次のオプションのいずれも選択する必要はありません。アーカイブ・ログを使用してデータ・ウェアハウスをリカバリできます。ただし次のオプションは、リカバリの場合のアーカイブ・ログベースのアプローチにおいていくつかのパフォーマンスの面で優れています。

- 抽出、変換およびロード

- 増分バックアップ

抽出、変換およびロード

ETLプロセスでは、データをデータ・ウェアハウスにロード(再ロード)するためにいくつかのOracle Databaseの機能またはツール、およびメソッドの組合せを使用します。これらの機能またはツールの構成要素は次のとおりです。

- トランスポータブル表領域。Oracleトランスポータブル表領域機能により、ユーザーはOracleデータベース間で表領域を迅速に移動することができます。この方法は、データベース間で大量データを移動するのに最も効率的です。Oracle Databaseにより、プラットフォーム間で表領域を転送できる機能が提供されます。ソース・プラットフォームとターゲット・プラットフォームが異なるエンディアンネスである場合、RMANによりターゲット・フォーマットに転送されている表領域が変換されます。

- SQL*Loader。SQL*Loaderにより、外部フラット・ファイルから1つのOracleデータベース上の複数の表にデータがロードされます。強力なデータ解析エンジンによって、あらゆるデータ形式のデータ・ファイルに対応できます。

- データ・ポンプ(エクスポート/インポート)。Oracle Databaseにより、Oracle Data Pumpテクノロジが提供され、これにより1つのデータベースから他のデータベースにデータおよびメタデータを高速で移動することが可能です。このテクノロジは、データ移動ユーティリティであるデータ・ポンプ・エクスポートおよびデータ・ポンプ・インポートの基本となります。

- 外部表。外部表機能は、既存のSQL*Loader機能を補足する機能です。この機能により、データベース内の表にあるデータと同様に、外部ソースのデータにアクセスできるようになります。

ETL計画およびNOLOGGING操作

アプローチの1つは、定期的にデータベースのバックアップをして、その週全体のETLプロセスを再作成するために必要なデータファイルを保存することです。リカバリが必要な場合、データ・ウェアハウスは最新のバックアップからリカバリされます。次に、従来のリカバリのシナリオで行われていたようにアーカイブREDOログを適用してロールフォワードを行うかわりに、データ・ウェアハウスはETLプロセスをリプレイすることでロールフォワードを行います。このパラダイムを使用する場合は、ETLプロセスを簡単にリプレイできることが前提となり、通常は各ETLプロセスの抽出ファイルのセットの保存も含まれます(たとえば不正なデータ送信の修復の必要があるかどうかを識別できるように、データ・ウェアハウスの多くはすでにベスト・プラクティスとしてこれを行っています)。

このアプローチのサンプル実装は、毎週末データ・ウェアハウスのバックアップを作成し、毎晩のETLプロセスをサポートするために必要なファイルを保存することです。したがって、データベースをリカバリするためには最大7日間分のETLプロセスが再適用されることになります。データ・ウェアハウスのリカバリにかかる時間は、テープからのリカバリ・スピードおよび以前のETL実行からのパフォーマンス・データに基づいて予測できます。

基本的にデータ・ウェアハウス管理者は、NOLOGGING操作を介してETLプロセスでのより高いパフォーマンスを獲得しており、その際は多少複雑であまり自動化されていないリカバリ・プロセスを通過する必要があります。データ・ウェアハウス管理者の多くは、これを価値のある代償だと理解しています。

このアプローチの弱点は、データ・ウェアハウスで発生した関連する変更のすべてを追跡する負荷がデータ・ウェアハウス管理者にかかるということです。このアプローチでは、ETLプロセスの範囲に入らない変更は取得されません。たとえば、いくつかのデータ・ウェアハウスでは、エンドユーザーが所有する表およびデータ構造を作成します。それらの変更はリカバリ時に失われます。この制限はエンドユーザーに伝達される必要があります。かわりに、管理者がユーザーに対して、すべてのプライベート・データベース・オブジェクトを別の表領域に作成するように指示し、リカバリ時には、従来のリカバリでその表領域をリカバリし、残りのデータベースはETLプロセスをリプレイすることでリカバリすることもできます。

要約すると、ベスト・プラクティスは、リカバリできない(NOLOGGING)トランザクションを含まないバックアップをリストアすることです。次にETLプロセスをリプレイしてデータを再ロードします。

ブロック変更トラッキング・ファイルのサイジング

ブロック変更トラッキング・ファイルのサイズは次の項目に比例します。

- データベース・サイズ(バイト)。ブロック変更トラッキング・ファイルには、データベース内のデータファイル・ブロックを表すデータが含まれます。データはおよそデータベースのサイズ全体の250000分の1です。

- 有効なスレッドの数。すべてのOracle Real Application Cluster(Oracle RAC)インスタンスは、同一のブロック変更トラッキング・ファイルにアクセスできます。ただし、インスタンスにより、ロックまたはノード間のブロック・スワッピングなしでトラッキング・ファイルの異なる領域が更新されます。個別のインスタンスに対してではなく、データベース全体に対してブロック変更トラッキング・ファイルを有効化できます。

- 変更済ブロックのメタデータ。ブロック変更トラッキング・ファイルは最後のバックアップ以来の変更に加えて、前のバックアップ間のすべての変更の記録を保持しています。トラッキング・ファイルは、最大で8個のバックアップの変更履歴を保持します。トラッキング・ファイルに8個のバックアップの変更履歴が含まれる場合は、Oracle Databaseにより最も古い変更履歴情報が上書きされます。

たとえばスレッドを1つのみ所有し、RMANリポジトリに8個のバックアップを保持する500GBのデータベースの場合は、20MBのブロック変更トラッキング・ファイルが必要です。

((Threads * 2) + number of old backups) * (database size in bytes)
------------------------------------------------------------------ = 20MB
250000

増分バックアップ

NOLOGGING操作が存在する、より自動化されたバックアップおよびリカバリ計画では、RMANの増分バックアップ機能を利用します。RMANが最初にリリースされて以来、増分バックアップはRMANの一部を構成しています。増分バックアップを使用すると、前回のバックアップ以降に変更されたブロックのみをバックアップすることができます。データファイルの増分バックアップでは、データファイルにあるすべての使用済ブロックのバックアップが要求されるのではなく、データの変更がブロックごとに取得されます。結果として取得されるバックアップのセットは、データファイル内のすべてのブロックが変更されないのであれば、通常すべてのデータファイルのバックアップより小さくて効率的です。

Oracle Databaseには、変更トラッキング・ファイル機能を実装して増分を高速化する機能があります。ブロック変更トラッキングを有効にする場合は、Oracle Databaseにより、すべてのデータベースの変更の物理的な場所が追跡されます。RMANにより自動的に変更トラッキング・ファイルが使用され、増分バックアップ中に読み込む必要のあるブロックが決定されて、バックアップするブロックに直接アクセスします。

増分アプローチ

このアプローチを使用する通常のバックアップおよびリカバリ計画は、毎週末データ・ウェアハウスをバックアップし、ETLプロセスが完了した後は毎晩データ・ウェアハウスの増分バックアップを取得します。増分バックアップは、従来のバックアップと同様に、NOLOGGING操作と同時に実行しないように注意してください。データ・ウェアハウスをリカバリするために、データベースのバックアップはリストアされ、毎晩の増分バックアップは再適用されます。NOLOGGING操作はアーカイブ・ログに取得されていませんが、NOLOGGING操作からのデータは増分バックアップ内にあります。さらに、前のアプローチとは異なり、このバックアップおよびリカバリ計画は、RMANを使用して完全に管理できます。

ETLをリプレイするアプローチおよび増分バックアップのアプローチの両方とも、多くのNOLOGGING操作で構成されているワークロードであるデータベースの効率的で安全なバックアップおよびリカバリのソリューションとしてお薦めします。バックアップおよびリカバリ計画においてNOLOGGING操作を考慮することが最も重要です。

要約すると、ベスト・プラクティスは、NOLOGGING操作のためオブジェクトをリカバリできない状態にしておくダイレクト・ロードの後、ブロック変更トラッキング機能を実装して増分バックアップを作成することです。

ベスト・プラクティスE: すべての表領域の重要度が同等でない場合

データベース内の各表領域を同様に処理することが最も単純なバックアップおよびリカバリのシナリオですが、Oracle Databaseでは、必要に応じて、バックアップおよびリカバリのシナリオを表領域ごとに考案できるような柔軟性を提供しています。

バックアップおよびリカバリという観点で見ると、データ・ウェアハウス内のすべての表領域が同等に重要だということはありません。この情報に基づいて、より効率的なバックアップおよびリカバリ計画を必要に応じて考案できます。バックアップおよびリカバリの基本粒度は表領域なので、異なる表領域には異なるバックアップおよびリカバリ計画が存在する可能性があります。最も基本的なレベルでは、一時表領域がバックアップされることはありません(RMANにより規定されるルール)。

さらに、いくつかのデータ・ウェアハウスでは、一時表領域ではないにもかかわらず、エンドユーザーが一時表領域と増分の結果を格納するスクラッチ領域専用の表領域であるために、一時表領域として機能している表領域があります。ビジネス要件によっては、これらの表領域をバックアップおよびリストアする必要はありません。かわりに、これらの表領域が失われた場合、ユーザーは所有するデータ・オブジェクトを再作成します。

データ・ウェアハウスの多くは、その他のデータより重要な一部データを持っています。たとえば、データ・ウェアハウス内の売上データは非常に重要で、リカバリの段階では、このデータはできるだけ早くオンラインにする必要があります。同一のデータ・ウェアハウス内では、企業のWebサイトからのクリック・ストリーム・データを格納している表の重要度がかなり低いことがあります。ビジネスを継続する上で、このデータが数日間オフラインになること、またはデータベース・ファイル損失時にクリック・ストリーム・データが数日間失われることは許容範囲内の場合があります。このシナリオでは、売上データを含む表領域は頻繁にバックアップする必要があり、一方でクリック・ストリーム・データを含む表領域は毎週1回または2回バックアップする必要があります。

12 データ・ウェアハウスのセキュリティ

この章では、データ・ウェアハウスのセキュリティの考慮事項について説明します。内容は次のとおりです。

- データ・ウェアハウスのセキュリティについて

- データ・ウェアハウスのセキュリティのロールおよび権限の使用

- データ・ウェアハウスの仮想プライベート・データベースの使用

- Oracle Label Securityの概要

- データ・ウェアハウスのファイングレイン監査の概要

- データ・ウェアハウスの透過的データ暗号化の概要

データ・ウェアハウスのセキュリティについて

データ・ウェアハウジングは、セキュリティに対して固有の課題を投げかけます。業務データ・ウェアハウスは、巨大なシステムであることが多く、多様なセキュリティ上のニーズに応えるとともに、数多くのユーザーに対応しています。また、データ・ウェアハウスは、柔軟性のある、強力なセキュリティ・インフラストラクチャを必要としますが、そのセキュリティ機能は、厳密なパフォーマンスとスケーラビリティなど条件付きの環境で動作する必要があります。

データ・ウェアハウスのセキュリティの必要性について

セキュリティに関するよく知られた基本要件の多くは、他のシステムの場合と同様にデータ・ウェアハウスにも当てはまります。不正なユーザーがアプリケーションを使用してデータにアクセスしたりデータを変更するのを防止し、アプリケーションおよび基礎データがハッカーに盗用されるのを回避し、正当なユーザーが必要に応じて利用できるようにデータを保持し、ユーザーの実行するアクティビティがシステムによって記録されている必要があります。

データ・ウェアハウスでは、複数のソースから統合されたデータが含まれるため、このような要件がさらに重要です。情報を盗もうとする側からすると、データ・ウェアハウスは企業内でも最も見返りが大きいターゲットの1つになり得ます。さらに、強固なセキュリティ・インフラストラクチャにより、有効性が大幅に改善され、データ・ウェアハウス環境のコストが削減されます。

データ・ウェアハウスのセキュリティの一般的な顧客シナリオには次のような事例があります。

- ある企業は、多くの部署や子会社で広く使用される企業データ・ウェアハウスを管理しています。その企業では、各部署の従業員には自分の部署に関連するデータのみを表示し、本社の従業員には全体像が表示されるセキュリティ・インフラストラクチャを必要としています。

- ある企業のデータ・ウェアハウスには、個人情報が格納されています。プライバシに関連する法では、個人情報の使用が規制される場合があります。データ・ウェアハウスでは、このような法律に準拠した方法でデータを管理する必要があります。

- 企業は、データ・ウェアハウスのデータをクライアントに販売します。クライアントは、購入または申し込んだデータのみを表示することができます。他のクライアントのデータを見ることはできません。

データ・ウェアハウスのセキュリティのロールおよび権限の使用

システム権限、オブジェクト権限およびロールは、基本的なデータベース・セキュリティを提供します。権限とロールは、ユーザーによるデータへのアクセスを制御し、ユーザーが実行可能なSQL文の種類を制限するように設計されています。ロールは異なるレベルのデータベース・アクセスを作成するために使用できる権限のグループです。たとえば、表およびプログラムを作成できるように、アプリケーション開発者に対してロールを作成できます。

必要な権限を持っている場合にかぎり、他のユーザーに権限およびロールを付与できます。ロールおよび権限の付与は、管理者レベルで開始します。データベースの作成で管理ユーザーSYSにより、すべてのシステム権限および事前定義されたOracleロールの作成と付与が行われます。ユーザーSYSは、他のユーザーに権限およびロールを付与でき、これらを付与されたユーザーに対して、他のユーザーに特定の権限を付与する権限を付与することもできます。明示的に付与された権限がない場合、ユーザーはデータベース内のどの情報にもアクセスできません。

ロールおよび権限はデータのセキュリティを規定し、データ・ウェアハウスにとってこれらのロールおよび権限の使用は不可欠です。これは多くのアプリケーションおよびツールを介してユーザーがデータにアクセスするためです。

データ・ウェアハウスの仮想プライベート・データベースの使用

仮想プライベート・データベース(VPD)によって、表、ビューまたはシノニムで直接、粒度の細かいレベルにセキュリティを規定できます。これは、セキュリティ・ポリシーが表、ビューまたはシノニムに直接連結されており、ユーザーがデータにアクセスする際にセキュリティをバイパスする方法がない場合に自動的に適用されるためです。述語を使用する動的に付与されているSQL文によって、VPDはデータへのアクセスを低いレベルに制限し、セキュリティ・ポリシーをデータベース・オブジェクトに適用します。また、完全なデータ分離の保証があれば、複数のユーザーが単一のデータベース・サーバーに格納された重要なデータへ直接セキュア・アクセスできます。VPDを使用すると、銀行顧客には顧客自身のアカウント履歴のみを見せ、複数の企業(競争企業同士)のデータを扱う企業の場合は、同じデータ・ウェアハウスからデータを扱っている企業にそれぞれのデータのみを見せることができます。さらに、VPDはセキュリティ関連列への制御アクセスを提供するので、従業員は自身の給与のみを確認できるようになります。

VPDは透過アプリケーションです。セキュリティはデータベース層で規定され、データベース内でのデータ・アクセスを制御するためのアプリケーション固有のロジックを考慮します。標準のアプリケーションおよびカスタム・ビルドのアプリケーションは、アプリケーション・コードの単一行の変更を行うことなく、ファイングレイン・アクセス制御を活用できます。

企業内では、VPDによって、アプリケーションの配布にかかる所有コストが削減されます。セキュリティの構築は、データにアクセスするすべてのアプリケーションに対してではなく、ウェアハウスに対して1回のみにすることができます。セキュリティは、ユーザーによるデータへのアクセスに関係なくデータベースによって規定されているためにより強固になっています。非定型の問合せのツールまたは新しいレポート・ライターを介してデータへアクセスするユーザーはセキュリティを経由できません。多くのユーザー・ツールと同様、様々なアプリケーションをサポートするEnterpise Data Warehouseにおいて、仮想プライベート・データベースは主要なテクノロジです。

仮想プライベート・データベースの動作方法

仮想プライベート・データベースは表、ビューまたはシノニムを使用するセキュリティ・ポリシーとの関連付けにより有効になります。管理者はPL/SQL DBMS_RLSパッケージを使用して、ポリシー・ファンクションとデータベース・オブジェクトをバインドします。連結したセキュリティ・ポリシーを使用するオブジェクトへの直接アクセスまたは間接アクセスにより、データベースはポリシーを実装したファンクションを参照します。ポリシー・ファンクションは、データベースがユーザーのSQL文に追加する述語(WHERE句)を戻すため、ユーザーによるデータへのアクセスの修正は透過的で動的です。

アプリケーション・コンテキストを使用すると、組織、サブスクライバ番号、アカウント番号、地位など、データベース管理者が重要と考える事実上すべての属性に基づいてアクセス条件を設定できます。たとえば、ユーザーが顧客、営業担当またはマーケティング・アナリストかどうか関係なく、売上データのウェアハウスは顧客番号に基づいたアクセスを規定できます。この場合、顧客はWeb上で注文履歴を確認でき(顧客自身の注文のみ)、営業担当は複数の注文を見ることができ(自身の企業の顧客の注文のみ)、また、アナリストの場合、過去の2四半期におけるすべての売上を分析できます。アプリケーション・コンテキストは、特定のオブジェクトでファイングレイン・アクセス制御ポリシーに適用する可能性のあるセキュアなデータ・キャッシュとして機能します。ユーザーがデータベースにログインすると、Oracle Databaseはユーザー・セッションのキャッシュ情報にアプリケーション・コンテキストを設定します。アプリケーション・コンテキストの情報は、開発者によって、個々のアプリケーションに関連した情報に基づいて定義されます。たとえば、地域別売上データを問い合せるレポート・アプリケーションは、ユーザーの地位および部門に関するアクセス制御に基づくことができます。この場合、アプリケーションはユーザーのログイン時に各ユーザーのアプリケーション・コンテキストを最初に設定し、各ユーザーの地位および部門の従業員と部署に関する表から問い合せられたデータを使用してコンテキストを移入できます。地域別売上表でVPDポリシーを実装しているパッケージは、ユーザーの地位および部門の各問合せを移入するためにこのアプリケーション・コンテキストを参照します。アプリケーション・コンテキストはパフォーマンスの劣化を引き起こす可能性のある実行中の副問合せを不要とみなします。

Oracle Label Securityの概要

Oracle Databaseのセキュリティ・オプションであるOracle Label Securityはラベルベースのアクセス制御を規定するために仮想プライベート・データベース(VPD)を拡張します。Oracle Label Securityは完全なVPD対応アプリケーションで、ラベル付きデータ管理によってVPDを拡大します。Oracle Label Securityは、セキュアなデータ・ウェアハウスの配布を簡略化し、基本的なセキュリティを提供します。

ラベルベースのアクセス制御を使用すると、表の行に機密性ラベルが割り当てられ、これらのラベルに基づいてデータへのアクセスが制御されて、適切なセキュリティ・ラベルがマークされたデータを確認できます。たとえば、組織が企業の機密情報とパートナに関する情報を区別する場合です。または、特定の主要なパートナと共有できる機密情報、および会計部門や営業部門などの特定の企業内部のグループのみがアクセス可能な機密情報などがある場合です。ラベル付きデータを管理できるということは、適切なデータ・アクセス・レベルで適切な人に情報を提供する組織にとって大きなメリットがあります。

Oracle Label Securityの動作方法

Oracle Label Securityは、ラベルのコレクション、ユーザーの認可およびセキュリティ強制オプションであるポリシーを使用します。ポリシーは、作成後にすべてのアプリケーション・スキーマまたは特定のアプリケーション表に適用できます。Oracle Label Securityは単一のデータ・ウェアハウス内で複数のポリシー定義をサポートします。ラベル定義、ユーザーの認可および強制オプションはポリシーごとに定義されます。たとえば、マーケティングのポリシーにはマーケティングのみのラベルやマネージャおよび上級副社長などのラベルが含まれます。

Oracle Label Securityは、行に含まれるラベル、各データベース・セッションに関連付けられたラベル、およびセッションに割り当てられたOracle Label Security権限に基づいて、データベース表の行へのアクセスを調整します。これによって、ユーザーにデータベースの標準的なシステム権限およびオブジェクト権限が付与された後、アプリケーション表に対するアクセスの調整が行われます。たとえば、ユーザーが表に対するSELECT権限を持っていると仮定します。ユーザーが表でSELECT文を実行すると、Oracle Label Securityは選択された各行を評価して、このユーザーが割り当てられている権限およびアクセス・ラベルに基づいて、選択された行にアクセス可能かどうかを判断します。また、Oracle Label Securityでは、UPDATE、DELETEおよびINSERT文に対するセキュリティ・チェックも行われます。ラベルは表およびマテリアライズド・ビューに適用することができ、マテリアライズド・ビューによってパフォーマンスが増加し、ラベルによりセキュリティが増加するために、データ・ウェアハウス環境で目的の柔軟性、スピードおよびスケーラビリティを実現します。

データ・ウェアハウスによりラベルを利用する方法

Oracle Label Securityを使用すると、複数のソースから利便性、管理性および集中管理によって、1つの大きなシステムに情報を統合できます。このセキュリティ・オプションはアプリケーション自体で行われるので、PL/SQLプログラミングを行う必要がありません。これにより、情報の統合およびデータ自体でのセキュリティの制限によるリスクの最小化が可能になり、行レベルでのデータへのアクセス制御によって精度の高いアクセス・セキュリティが提供されます。

データ・ウェアハウスのファイングレイン監査の概要

ファイングレイン監査により、コンテンツに基づいたデータ・アクセスの監視ができます。この監査では、監査するレコードの列および条件を指定できます。この監査では、監査するレコードの列および条件を指定でき、指定列を使用した接続で使用したDML文の特定のタイプに対する監査の制限を条件に含むことができます。また、監査イベントの発生時におけるルーチン名を指定できます。このルーチンは管理者に通知またはアラートするか、エラーおよび異常を処理できます。たとえば、中央税務当局で使用すると、納税申告へのアクセスを追跡し従業員による詮索を防止できます。特定の表でSELECT文を発行した特定のユーザーを把握するだけでは十分ではなく、日常業務に必要ではない情報にアクセスしようとする際のさらに細かいレベルでの監査が強固なセキュリティに必要です。この場合、列または行のSELECT文には仕事に無関係な情報が含まれます。ファイングレイン監査はこの機能を提供します。

ファイングレイン監査はDBMS_FGAパッケージまたはデータベース・トリガーを使用してユーザー・アプリケーションで実装できます。

データ・ウェアハウスの透過的データ暗号化の概要

透過的データ暗号化によって、オペレーティング・システムのファイルに格納されるデータとして、データベース列にある機密データを暗号化できます。データベース外部のセキュリティ・モジュールで暗号キーの管理および記憶領域をセキュアに保ちます。既存のアプリケーションに暗号化したルーチンを埋め込む必要がなく、コストおよび暗号化の複雑さを大幅に削減しました。いくつかの単純なコマンドを使用することで、機密のアプリケーション・データは暗号化されます。

多くの暗号化ソリューションは、アプリケーション・コード内の暗号化ファンクションに対する特定のコールを必要とします。これには高いコストが必要で、アプリケーションの広範囲にわたる理解、およびソフトウェアの書込みと保持の技術が要求されます。一般的に、ほとんどの組織には既存のアプリケーションを修正して暗号化ルーチンに対するコールを作成する時間や専門家が不足しています。透過的データ暗号化は、Oracle Databaseに埋め込まれた暗号化により暗号化問題を処理します。これはSQL* Loaderではなく直接パス・ロードを使用して行われることに注意してください。

SQLを介して実行されるアプリケーション・ロジックは変更することなく実行を継続します。言い換えれば、アプリケーションはアプリケーション表にデータを挿入するために同じ構文を使用でき、Oracle Databaseはディスクへ情報を書き込む前にデータを自動的に暗号化します。後続のSELECTオプションには透過的に復号化されたデータが含まれ、アプリケーションは通常の作業を継続します。

索引

A B C D E F G H I M N O P Q R S T U V W

A

追加

マッピング演算子, 5.4

分析機能, 7.1 分析SQL, 7.1 ARCHIVELOGモード

ベスト・プラクティス, 11.2.1

属性のプロパティ, 設定, 5.7 属性

接続, 5.6.3

レベル属性, 4.4.1.2

プロパティの設定, 5.7

自動バインド・ルール, 4.4.2.2

B

バックアップ, 11.1

バックアップとリカバリ, 11.1

ベスト・プラクティス, 11.2

ベスト・プラクティス

ARCHIVELOGモード, 11.2.1

バックアップとリカバリ, 11.2

NOLOGGING, 11.2.4

読取り専用表領域, 11.2.3

RMAN, 11.2.2

表領域の相違, 11.2.5

バインド

自動バインド, ルール, 4.4.2.2

Bツリー索引, 10.2.3

C

移動平均の計算, 7.1.8

相対的な寄与率の計算, 7.1.6

列統計, 10.1.1

一般的なタスク

データ・ウェアハウス, 1.2.2

COMPATIBLEパラメータ, 2.3.3 COMPRESS句, 10.2.4.2 圧縮, 10.2.4 圧縮アドバイザ・インタフェース, 10.2.4.1 接続

属性, 5.6.3

グループ, 5.6.2

演算子, 5.6

CPU, 2.2.1.1 「外部表の作成」ウィザード, 4.3.1 作成

マッピング, 5

CUBE関数, 7.1.2 キューブ, 4.5

ディメンション, 4.5.1.2

例, 4.5.1.3

メジャー, 4.5.1.1

リレーショナル実装, 4.5.2.1

D

データ圧縮, 9.3.1

データ・ウェアハウス

一般的なタスク, 1.2.2

主な特性, 1.2.1

設定, 2.2, 2.3

ツール, 1.4

データ・ウェアハウスのセキュリティ, 12 DB_BLOCK_SIZEパラメータ, 2.3.3 DB_FILE_MULTIBLOCK_READ_COUNTパラメータ, 2.3.3 DBMS_COMPRESSIONパッケージ, 10.2.4.1 DBMS_STATSパッケージ, 10.1.1 ddユーティリティ, 2.2.2.1 定義

マッピング, 5

並列度(DOP), 10.3.1.2 稠密化, 7.2 ディメンション

ディメンション・ロール, 4.4.1.4

例, 4.4.1.6

階層, 4.4.1.3

実装, 4.4.2

レベル属性, 4.4.1.2

レベルの関係, 4.4.1.5

スター・スキーマ実装, 4.4.2.1

ディスク

要件, 2.2.1.3

E

実行計画

分析, 10.1.2

EXPLAIN PLAN文, 10.1.2 実行計画, 10.1.2 外部表

新規定義の作成, 4.3.1

定義, 4.3.1

作成用ウィザード, 4.3.1

「フラット・ファイル」も参照

F

ファイングレイン監査

データ・ウェアハウス, 12.5

フラット・ファイル

「外部表」も参照

G

グループ・プロパティ, 5.7

GROUPING関数, 7.1.3

GROUPING SETS関数, 7.1.4

グループ

接続, 5.6.2

プロパティの設定, 5.7

H

ハードウェア構成, 2.2.1

確認, 2.2.2

階層

説明, 4.4.1.3

ヒント, 10.1.3

I

実装

リレーショナル・キューブ, 4.5.2.1

スター・スキーマ, 4.4.2.1

索引統計, 10.1.1 索引

ビットマップ, 10.2.3

最適化, 9.2

SQLアクセス・アドバイザを使用した最適化, 9.2

初期化パラメータ

設定, 2.3.3

行間計算

実行, 7.1.7

I/O, 2.2.1.4, 9.1.1.2

監視, 9.1.1.2

M

マッピング演算子

説明, 5.1

追加, 5.4

接続, 5.6

編集, 5.5

リポジトリ・オブジェクトとの同期化, 5.8

タイプ, 5.3.1

マッピング演算子, 設定, 5.7 マッピング

説明, 5.1

作成, 5

定義, 5

マテリアライズド・ビュー, 10.2.2 メモリー, 2.2.1.2 メモリー管理

パラメータ, 2.3.1

必要なメモリー, 2.2.1.2 MERGE PARTITION操作, 9.3.1 MOVE PARTITION操作, 9.3.1

N

NOLOGGING

ベスト・プラクティス, 11.2.4

O

データのオフロード

ローリング・ウィンドウ, 8.2

演算子の属性, 5.6.3 演算子のプロパティ

設定, 5.7

演算子

接続, 5.6

編集, 5.5

リポジトリ・オブジェクトとの同期化, 5.8

演算子, マッピング, 5.1

追加, 5.4

接続, 5.6

編集, 5.5

タイプ, 5.3.1

オプティマイザ統計, 10.1.1 OPTIMIZER_FEATURES_ENABLEパラメータ, 2.3.3 Oracle Label Security, 12.4

データ・ウェアハウス, 12.3

Orionユーティリティ, 2.2.2.3

P

パラレル実行, 10.3.1

動作, 10.3.1.1

パラレル問合せ, 9.1.1.1, 10.3.1

監視, 9.1.1.1

PARALLEL_ADAPTIVE_MULTI_USERパラメータ, 2.3.3 PARALLEL_MAX_SERVERSパラメータ, 2.3.3 パラメータ

COMPATIBLE, 2.3.3

DB_BLOCK_SIZE, 2.3.3

DB_FILE_MULTIBLOCK_READ_COUNT, 2.3.3

OPTIMIZER_FEATURES_ENABLED, 2.3.3

PARALLEL_ADAPTIVE_MULTI_USER, 2.3.3

PARALLEL_MAX_SERVERS, 2.3.3

QUERY_REWRITE_ENABLED, 2.3.3

QUERY_REWRITE_INTEGRITY, 2.3.3

STAR_TRANSFORMATION_ENABLED, 2.3.3

パラメータ

初期化, 2.3.3

メモリー管理, 2.3.1

パーティション外部結合, 7.2 パーティション・プルーニング, 10.2.1.1 パーティション, 10.2.1 パーティションワイズ結合, 10.2.1.2 パフォーマンス

圧縮による向上, 10.2.4

ヒントの使用, 10.1.3

クエリー・リライトの使用, 10.2.2

SQLアクセス・アドバイザの使用, 10.1.4

SQLチューニング・アドバイザの使用, 10.1.4

権限

データ・ウェアハウスのセキュリティ, 12.2

プロパティ

設定, 5.7

Q

クエリー・リライト, 2.3.3, 2.3.3, 4.4, 8.1.1, 10.2.2

QUERY_REWRITE_ENABLEDパラメータ, 2.3.3

QUERY_REWRITE_INTEGRITYパラメータ, 2.3.3

R

レンジ・パーティション化された表, 9.3.1

RANK関数, 7.1.5

読取り専用表領域

ベスト・プラクティス, 11.2.3

リフレッシュ

データ・ウェアハウス, 8

リソース使用量, 10.2

最小化, 10.2

リソース・マネージャ, 9.1.2 リソース使用量, 10.2 リライト

問合せ, 2.3.3, 2.3.3

RMAN

ベスト・プラクティス, 11.2.2

ロール

ディメンション・ロール, 4.4.1.4

データ・ウェアハウスのセキュリティ, 12.2

ローリング・ウィンドウ, 8.2 ROLLUP関数, 7.1.1

S

セキュリティ

データ・ウェアハウス, 12

スパース性, 7.2 SPLIT PARTITION操作, 9.3.1 SQLアクセス・アドバイザ, 10.1.4

パーティション化の評価, 10.2.1.3

索引の最適化, 9.2

SQLチューニング・アドバイザ, 10.1.4 STAR_TRANSFORMATION_ENABLEDパラメータ, 2.3.3 統計

オプティマイザ, 10.1.1

記憶域

最適化, 9.3

同期化

演算子とリポジトリ・オブジェクト, 5.8

システム統計, 10.1.1

T

表統計, 10.1.1

table_compress句, 10.2.4.2

表

「外部表」も参照

ツール

データ・ウェアハウス, 1.4

透過的データ暗号化

データ・ウェアハウス, 12.6

U

UTLXPLAN.SQLスクリプト, 10.1.2

V

仮想プライベート・データベース

動作, 12.3.1

データ・ウェアハウス, 12.3

W

待機イベント, 10.3.2

WITH句, 7.3

ウィザード

「外部表の作成」ウィザード, 4.3.1

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