| Oracle Business Intelligence Standard Edition Oneチュートリアル リリース10g（10.1.3.2.1） E05487-01 |
|
 戻る |
 次へ |
この章では、データ・マートに関連する基本概念をいくつか説明し、このマニュアルの残りの部分で使用する作業上の定義をいくつか定めます。定義と用語に関しては、ユーザーとベンダーの間で合意に達しているものも数多くありますが、完全なコンセンサスに達しているわけではありません。「データ・マートとは何か」というような基本的な事項であっても、十数人のユーザーに聞いてみれば、半分くらいのユーザーは、大筋では同じでも微妙に異なる答えを返してくると思われます。この章では、いくつかの定義をざっと見て、何がデータ・マートで何がデータ・マートでないかを説明します。
この章は次のトピックで構成されています。
データ・マートとは、簡易形式のデータ・ウェアハウスで、営業、財務、マーケティングなど、1つのサブジェクト（または機能領域）に対象を絞ったものです。データ・マートは、多くの場合、組織の1部門で構築および管理します。データ・マートは、1つのサブジェクトに対象を絞ったものであるため、ごく少数のソースからデータを引き出すのが普通です。このソースとしては、内部の業務系システム、中央のデータ・ウェアハウスまたは外部のデータが考えられます。
データ・マートと異なり、データ・ウェアハウスは、複数のサブジェクト・エリアを対象としており、通常の場合、社内の情報技術（IT）グループなど、中央の組織単位で実装および管理します。これは多くの場合、中央データ・ウェアハウスまたはエンタープライズ・データ・ウェアハウスと呼びます。通常の場合、データ・ウェアハウスは、複数のソース・システムのデータをアセンブルします。
これらの基本定義には、データ・マートのサイズや、データ・マートに含まれる意思決定支援データの複雑さを制限するものはありません。それでも、通常の場合、データ・マートはデータ・ウェアハウスに比べて、サイズも複雑さも小さいため、構築と運用がしやすくなるのが普通です。表A-1は、データ・ウェアハウスとデータ・マートの基本的な違いを要約したものです。
データ・マートには、基本的に従属型と独立型の2種類があります。このカテゴリ分けは主に、データ・マートにフィードするデータソースに基づいています。従属型データ・マートは、すでに作成されている中央のデータ・ウェアハウスからデータを引き出します。これに対して独立型データ・マートは、データの業務系ソースまたは外部ソース、あるいはその両方から直接データを引き出すことによって構築されるスタンドアロンのシステムです。
独立型データ・マートと従属型データ・マートの大きな違いは、データ・マートに移入する仕組み、つまり、ソースからデータを取得してデータ・マートに入力する仕組みです。抽出、変換およびロード（ETL）プロセスと呼ぶこの手順では、業務系システムのデータを移動し、フィルタリングして、データ・マートにロードします。
従属型データ・マートの場合、フォーマットと要約が行われた（クリーンな）データが、中央のデータ・ウェアハウスにすでにロードされているため、このプロセスは、ある程度簡略化されます。従属型データ・マートのETLプロセスは、選択されたデータ・マートのサブジェクトに関連するデータの正しいサブセットを特定し、（多くの場合、要約されたフォームで）そのコピーを移動するプロセスがほとんどです。
ただし、独立型データ・マートの場合は、ETLプロセスのあらゆる面に対処する必要があり、その処理量は、中央のデータ・ウェアハウスを扱う場合と同じくらい大きくなります。1つのサブジェクトに対象を絞っているため、データ・マートはデータ・ウェアハウスに比べて、ソースの数も関連するデータの量も少なくなります。
これら2種類のデータ・マートを作成した背景にある動機も、やはりそれぞれ異なっています。従属型データ・マートは通常、パフォーマンスと可用性の改善、管理の向上、および具体的な部門に関連するデータにローカル・アクセスすることによる通信コストの引下げを実現する目的で構築します。多くの場合、独立型データ・マートは、ソリューション開発期間を短縮化する必要に迫られて作成しています。
簡単に説明すると、データ・マートを実装するための主な手順は、スキーマの設計、物理的なストレージの構築、ソース・システムのデータのデータ・マートへの移入、十分な情報を得た意思決定ができることを目的としたデータ・マートへのアクセス、および時間の経過に応じた管理です。
この項は次のトピックで構成されています。
データ・マートのプロセスにおける最初の手順は設計です。この手順では、データ・マートに対するリクエストの開始から、要件に関する情報の収集を経て、データ・マートの論理設計および物理設計の開発に至るまでの作業をすべて行います。設計手順で行う作業は次のとおりです。
ビジネス要件と技術要件の収集
データソースの特定
適切なデータのサブセットの選択
データ・マートの論理構造および物理構造の設計
この手順では、データ・マートに関連する物理データベースおよび論理構造を作成して、データへの高速かつ効率的なアクセスを図ります。この手順で行う作業は次のとおりです。
表領域など、データ・マートに関連する物理データベースおよびストレージ構造の作成
設計手順で定義した表や索引など、スキーマ・オブジェクトの作成
表とアクセス構造を設定する最良の方法の判断
移入手順では、ソースからのデータの取得、データのクリーンアップ、正しいフォーマットおよび詳細レベルへのデータの変更、およびデータ・マートへのデータの移動に関連する作業をすべて行います。より形式的に説明すると、移入手順で行う作業は次のとおりです。
ターゲット・データ構造へのデータソースのマッピング
データの抽出
データのクレンジングと変換
データ・マートへのデータのロード
メタデータの作成と格納
アクセス手順では、データのクエリー、データの分析、レポート、チャートおよびグラフの作成、それらの公開など、データを使用できるようにします。通常の場合、エンド・ユーザーは、フロントエンドのグラフィカル・ツールを使用して、データベースにクエリーを送信して、クエリーの結果を表示します。アクセス手順で実行する必要のある作業は次のとおりです。
フロントエンドのツールを使用するための、中間レイヤーの設定。メタレイヤーというこのレイヤーが、データベース構造とオブジェクト名をビジネス用語に変換し、エンド・ユーザーが、ビジネス機能に関連する用語を使用して、データ・マートと対話できるようになります。
これらのビジネス・インタフェースの運用と管理
フロントエンドのツールを使用して送信されたクエリーを高速かつ効率的に実行できるような、要約された表などのデータベース構造の設定と管理
この手順では、存続期間全体にわたって、データ・マートを管理します。この手順で実行する管理作業は次のとおりです。
データへのセキュアなアクセスの実現
データの増加の管理
パフォーマンスの改善に向けたシステムの最適化
システム障害が発生した場合でもデータの可用性を確保
