| Oracle® Databaseデータ・ウェアハウス・ガイド 12c リリース1 (12.1) B71318-06 |
|
 前 |
 次 |
この章では、Oracleのデータ・ウェアハウス実装の概要について説明します。この章の内容は次のとおりです。
データ・ウェアハウスは、ビジネス・インテリジェンス・アクティビティを可能にするよう設計されたデータベースです。ユーザーの理解を深め、組織のパフォーマンスを向上させる目的があります。これは、トランザクション処理用ではなく、問合せおよび分析用に設計され、通常、トランザクション・データから導出された履歴データが含まれますが、他のソースからのデータを含めることもできます。データ・ウェアハウスは分析処理をトランザクション処理の負荷と分離し、組織で、様々なソースからのデータを整理統合できるようにします。これは、次のような場合に役立ちます。
履歴データのメンテナンス
ビジネスをよりよく理解し改善するためのデータの分析
データ・ウェアハウス環境には、リレーショナル・データベースに加えて、抽出、転送、変換、ロード(ETL)のソリューションや、統計分析、レポート、データ・マイニング機能、クライアント分析ツール、および、データ収集処理や有益かつ実用的な情報へのデータ変換処理、ビジネス・ユーザーへのデータ配信処理を管理するその他のアプリケーションが含まれます。
ビジネス・インテリジェンスの向上という目的を達成するため、データ・ウェアハウスでは複数ソースから収集されたデータを操作します。ソース・データは、内部開発システム、市販アプリケーション、サード・パーティ・データ・シンジケータなどのソースから収集されます。データには取引、製造、マーケティング、人事管理などが含まれます。今日のビッグ・データの世界では、データは、Webサイトでの何十億回ものクリックの一つ一つであったり、複雑な装置に組み込まれたセンサーからの大量のデータ・ストリームの場合もあります。
データ・ウェアハウスは、オンライン・トランザクション処理(OLTP)システムとは別個のものです。データ・ウェアハウスでは、分析ワークロードをトランザクション・ワークロードから分離します。したがって、データ・ウェアハウスは非常に読取り指向のシステムです。書込みおよび更新に対し、読取りデータははるかに大量です。これにより、分析のパフォーマンスが非常に向上する上、トランザクション・システムへの影響を避けられます。多くのソースからのデータを統合するようデータ・ウェアハウス・システムを最適化し、組織内の真の単一ソースにするという主要目的を達成できます。すべてのユーザーが参照可能な、一貫性のあるデータのソースを保持することには、大きな価値があります。多くの論争を防ぎ、意思決定を効率化します。
データ・ウェアハウスには通常、複数月または複数年のデータが格納されており、履歴の分析をサポートします。データ・ウェアハウスのデータは通常、複数のデータ・ソースからの抽出、変換およびロード(ETL)プロセスを通してロードされます。最新のデータ・ウェアハウスは、データ・ウェアハウスをホストするデータベース上で、すべてまたはほとんどのデータ変換が行われる抽出、ロードおよび変換(ELT)アーキテクチャに移行しつつあります。ETLプロセスの定義がデータ・ウェアハウスの設計作業の非常に大きな部分であることに注意することが重要です。同様に、データ・ウェアハウスの稼動後は、ETL操作の速度と信頼性がデータ・ウェアハウスの基盤になります。
データ・ウェアハウスのユーザーは、多くの場合、時間に関連するデータの分析を実行します。例として、昨年の連結売上高、在庫分析、製品別収益および顧客別収益があります。しかし、時間中心か否かは別として、どんなに適切に見えるデータでも、申し分ない設計のデータ・ウェアハウスが要求を十分満たすだけの柔軟性を備えていても、ユーザーはデータを分析することを望みます。ユーザーは、非常に集約されたデータを必要とする場合もあれば、詳細なドリル・ダウンが必要な場合もあります。より高度な分析に、傾向分析とデータ・マイニングがあり、既存のデータを使用して傾向または今後を予測します。データ・ウェアハウスは、ミドルウェア・ビジネス・インテリジェンス環境で使用されるベースのエンジンとして機能し、エンド・ユーザーにレポート、ダッシュボードその他のインタフェースを提供します。
前述の説明ではデータ・ウェアハウスという用語に注目してきましたが、説明する必要がある重要な用語が他に2つあります。それはデータ・マートとオペレーショナル・データ・ストア(ODS)です。
データ・マートはデータ・ウェアハウス同様の役割を果たしますが、その適用範囲は意図的に制限されています。これは、ある特定の部門または業務に対して提供されます。データ・ウェアハウスに対するデータ・マートのメリットは、適用範囲が制限されているため、高速で作成できる点です。ただし、データ・マートでは非一貫性の問題も発生します。データ・マート全体でデータおよび計算の定義の一貫性を保つため、厳しい統制をとります。この問題は広く知られているため、データ・マートには2つの形式があります。非依存型データ・マートは、ソースのデータが直接入力されるものです。情報が一貫せず、孤立してしまう可能性があります。依存型データ・マートは、既存のデータ・ウェアハウスから入力されるものです。依存型データ・マートでは非一貫性の問題は回避できますが、企業レベルのデータ・ウェアハウスがすでに存在している必要があります。
オペレーショナル・データ・ストアは日常操作のサポートを目的としたものです。ODSのデータはクリーンアップされ、妥当性チェック済ですが、履歴までは対応されていません。つまり、当日のデータのみに対応しています。ODSはデータ・ウェアハウスで扱うことが可能な、豊富な履歴を扱う問合せをサポートするかわりに、データ・ウェアハウスにまだロードされていない最新のデータにアクセスする環境をデータ・ウェアハウスに提供します。ODSは、データ・ウェアハウスのロードのソースとして使用される場合もあります。データ・ウェアハウスのロード技術の進歩に伴い、データ・ロードのソースとしてのODSのニーズは低くなってきました。代替として、常時トリクルフィード・システムにより、データ・ウェアハウスのほぼリアルタイムのロードが可能です。
データ・ウェアハウスを導入する際は、William Inmon氏が提唱するデータ・ウェアハウスの次の特性を十分に理解する必要があります。
サブジェクト指向
データ・ウェアハウスは、データの分析に役立つように設計されています。たとえば、会社の売上データの詳細が必要な場合は、売上を中心とするデータ・ウェアハウスを作成できます。このデータ・ウェアハウスでは、「昨年、この品目を最も多く購入した顧客は誰だったか」、「来年、この品目を最も多く購入しそうな顧客は誰か」のような質問に答えることができます。このようにデータ・ウェアハウスをサブジェクト(この場合は売上)別に定義できるため、データ・ウェアハウスの使用はサブジェクト指向となります。
統合化
統合化は、サブジェクト指向と密接な関係があります。データ・ウェアハウスでは、異なるソースのデータを、一貫したフォーマットに入れる必要があります。また、ネーミングの競合や単位の不整合などの問題を解決する必要があります。これが達成されれば、データ・ウェアハウスは統合化されたことになります。
恒常的
時系列
データ・ウェアハウスでは、時系列という用語が意味する、時間経過に伴う変化に重点が置かれています。ビジネスの動向を見いだし、背後に潜むパターンおよび関係性を識別するには、アナリストは大量のデータを必要とします。これは、オンライン・トランザクション処理(OLTP)システムとは非常に対照的です。OLTPシステムでは、パフォーマンス要件のために、履歴データをアーカイブに移動させる必要があります。
OLTPシステムとデータ・ウェアハウスには重要な相違点があります。この2つのシステムにおける大きな違いの1つは、OLTP環境での一般的なデータ正規化タイプは第3正規形(3NF)ですが、データ・ウェアハウスでは、そうとは限らないということです。
データ・ウェアハウスおよびOLTPシステムの要件は、大きく異なります。次に、典型的なデータ・ウェアハウスとOLTPシステムのいくつかの違いの例を示します。
処理負荷
データ・ウェアハウスは、非定型の問合せおよびデータ分析に適応するように設計されています。データ・ウェアハウスの処理負荷は、事前には不明な場合があります。このため、データ・ウェアハウスは、様々な問合せ操作および分析操作を適切に実行できるように最適化する必要があります。
OLTPシステムは、事前に定義された操作のみサポートします。アプリケーションは、これらの操作のみサポートするようにチューニングまたは設計されている場合があります。
データ修正
データ・ウェアハウスのデータは、大量データ修正の技術を使用して、ETLプロセスによって定期的に(毎晩、毎週など)更新されます。データ・マイニングなどの分析ツールを使用して、関連する確率から予測を作成したり、顧客を市場セグメントに当てはめたり、顧客プロファイルを作成したりする場合を除き、データ・ウェアハウスのエンド・ユーザーは、データ・ウェアハウスを直接更新することはありません。
OLTPシステムでは、エンド・ユーザーが機械的に、個々のデータ修正の都度、修正文を発行します。OLTPデータベースは常に最新であり、各ビジネス・トランザクションの現在の状態が反映されます。
スキーマ設計
データ・ウェアハウスは、部分的に非正規化されたスキーマを使用して、問合せおよび分析のパフォーマンスを最適化します。
OLTPシステムは、完全に正規化されたスキーマを使用して、更新/挿入/削除のパフォーマンスを最適化し、データ整合性を保証します。
典型的な操作
典型的なデータ・ウェアハウスの問合せでは、膨大な数の列がスキャンされる場合があります。たとえば、「先月のすべての顧客に対する合計売上の検索」などの場合です。
典型的なOLTP操作では、少数のレコードのみがアクセスされます。たとえば、「この顧客に対する現在の注文の取出し」などの場合です。
履歴データ
データ・ウェアハウスには、通常、長い年月分のデータが格納されています。これは、履歴の分析およびレポートをサポートするためです。
OLTPシステムには、通常、数週間または数か月分のデータのみが格納されています。OLTPシステムには、現行のトランザクション要件を満たすために必要な履歴データのみが格納されます。
Oracleデータ・ウェアハウス管理者または設計者として、次のタスクを行うことが予想されます。
データ・ウェアハウスとして使用するためのOracle Databaseの構成
データ・ウェアハウスの設計
データベース・ソフトウェアおよびデータ・ウェアハウス・ソフトウェアの新規リリースへのアップグレードの実行
スキーマ・オブジェクトの管理(表、索引およびマテリアライズド・ビューなど)
ユーザーおよびセキュリティの管理
抽出、変換およびロード(ETL)の各プロセスに使用するルーチンの開発
データ・ウェアハウス内のデータに基づいたレポートの作成
必要に応じたデータ・ウェアハウスのバックアップおよびリカバリの実行
データ・ウェアハウスのパフォーマンスの監視と必要に応じた予防処理または修正処理
中小規模のデータ・ウェアハウス環境では、これらのタスクを単独で実行する可能性があります。大企業のような環境の場合、ジョブはデータベース・セキュリティまたはデータベースのチューニングなどの専門を持つ数名のDBAおよび設計者に分割されます。
これらのタスクについては、次で説明されています。
パーティション化の詳細は、Oracle Database VLDBおよびパーティショニング・ガイドを参照してください。
データベース・セキュリティの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。
データベースのパフォーマンスの詳細は、Oracle Databaseパフォーマンス・チューニング・ガイドおよびOracle Database SQLチューニング・ガイドを参照してください。
バックアップおよびリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
ODIの詳細は、『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』を参照してください。
図1-1に、データ・ウェアハウスの単純なアーキテクチャを示します。エンド・ユーザーは、複数のソース・システムから導出されたデータに、データ・ウェアハウスを通じて直接アクセスします。
図1-1では、従来のOLTPシステムのメタデータと生データは、付加的なデータであるサマリー・データと同様に示されています。サマリーは、コストが高く、実行に時間のかかる共通の操作を事前に計算し、1秒未満でデータ取得するためのメカニズムです。たとえば、典型的なデータ・ウェアハウス問合せとして、8月の売上などを取り出す問合せがあります。Oracleデータベースでは、サマリーをマテリアライズド・ビューと呼びます。
データ･ウェアハウス・アーキテクチャの中心としての、統合された生データの記憶域は通常、エンタープライズ･データ･ウェアハウス(EDW)と呼ばれます。すべての関連するビジネス情報を、最も詳細な形式で保持することで、EDWは組織のビジネスのあらゆる角度からの考察を可能にします。
図1-2に示すように、業務系データはウェアハウスに格納する前にクレンジングして加工しておく必要があります。これはプログラムで処理できますが、ほとんどのデータ・ウェアハウスではステージング・エリアが使用されます。ステージング･エリアにより、データ･クレンジングおよび複数のソース･システムからの業務系データの統合が簡素化されますが、企業のすべての関連情報が統合される、エンタープライズ･データ･ウェアハウスでは特に有効です。図1-2に、この典型的なアーキテクチャを示します。
図1-2のアーキテクチャはきわめて一般的ですが、ウェアハウスのアーキテクチャを組織内のグループごとにカスタマイズすることもできます。そのためには、特定の業務に合せて設計されたデータ・マートを追加します。図1-3の例では、発注、受注、在庫が分離されています。この例で、ファイナンシャル・アナリストは発注と受注の履歴データを分析したり、履歴データをマイニングして顧客の行動の予測を作成できます。
図1-3 データ・ウェアハウス・アーキテクチャ(ステージング・エリアおよびデータ・マートを伴う)
注意:
データ･マートは、物理的にインスタンス化あるいはビューを介して完全に論理的に実装できます。さらに、データ･マートはエンタープライズ･データ･ウェアハウスと共通の場所に配置することも、別のシステムとして構築することもできます。エンタープライズ･データ･ウェアハウスとその周辺のデータ･マートを伴う、エンドツーエンドのデータ･ウェアハウス･アーキテクチャの構築については、このマニュアルでは対象としません。
