データウェアハウジング-アーキテクチャ
この章では、データウェアハウスの設計とアーキテクチャのビジネス分析フレームワークについて説明します。
ビジネス分析フレームワーク
ビジネスアナリストは、データウェアハウスから情報を取得してパフォーマンスを測定し、市場の他のビジネスホルダーに勝つために重要な調整を行います。データウェアハウスを持つことには、次の利点があります-
データウェアハウスは情報を迅速かつ効率的に収集できるため、ビジネスの生産性を向上させることができます。
データウェアハウスは、顧客とアイテムの一貫したビューを提供するため、顧客関係の管理に役立ちます。
データウェアハウスは、一貫性のある信頼できる方法で長期間にわたる傾向やパターンを追跡することにより、コストを削減するのにも役立ちます。
効果的かつ効率的なデータウェアハウスを設計するには、ビジネスニーズを理解して分析し、 business analysis framework。データウェアハウスの設計に関しては、人それぞれに異なる見解があります。これらの見解は次のとおりです-
The top-down view −このビューでは、データウェアハウスに必要な関連情報を選択できます。
The data source view −このビューには、運用システムによってキャプチャ、保存、および管理されている情報が表示されます。
The data warehouse view−このビューには、ファクトテーブルとディメンションテーブルが含まれます。これは、データウェアハウス内に格納されている情報を表します。
The business query view −エンドユーザーの視点から見たデータの見方です。
3層データウェアハウスアーキテクチャ
通常、データウェアハウスは3層アーキテクチャを採用しています。以下は、データウェアハウスアーキテクチャの3つの層です。
Bottom Tier−アーキテクチャの最下層は、データウェアハウスデータベースサーバーです。リレーショナルデータベースシステムです。バックエンドツールとユーティリティを使用して、データを最下層にフィードします。これらのバックエンドツールとユーティリティは、抽出、クリーン、ロード、および更新機能を実行します。
Middle Tier −中間層には、次のいずれかの方法で実装できるOLAPサーバーがあります。
拡張リレーショナルデータベース管理システムであるリレーショナルOLAP（ROLAP）による。ROLAPは、多次元データの操作を標準のリレーショナル操作にマップします。
多次元データと操作を直接実装する多次元OLAP（MOLAP）モデルによる。
Top-Tier−この層はフロントエンドクライアント層です。このレイヤーには、クエリツールとレポートツール、分析ツール、データマイニングツールが含まれます。
次の図は、データウェアハウスの3層アーキテクチャを示しています-
データウェアハウスモデル
データウェアハウスアーキテクチャの観点から、次のデータウェアハウスモデルがあります。
- 仮想倉庫
- データ市場
- エンタープライズウェアハウス
仮想倉庫
運用データウェアハウスのビューは、仮想ウェアハウスと呼ばれます。仮想倉庫の構築は簡単です。仮想ウェアハウスを構築するには、運用データベースサーバーに過剰な容量が必要です。
データ市場
データマートには、組織全体のデータのサブセットが含まれています。このデータのサブセットは、組織の特定のグループにとって価値があります。
言い換えれば、データマートには特定のグループに固有のデータが含まれていると言えます。たとえば、マーケティングデータマートには、アイテム、顧客、および販売に関連するデータが含まれている場合があります。データマートは対象に限定されています。
データマートについて覚えておくべきポイント-
データマートの実装には、ウィンドウベースまたはUnix / Linuxベースのサーバーが使用されます。これらは低コストのサーバーに実装されています。
実装データマートサイクルは、短期間、つまり数か月や数年ではなく数週間で測定されます。
データマートの計画と設計が組織全体に及ばない場合、データマートのライフサイクルは長期的には複雑になる可能性があります。
データマートはサイズが小さいです。
データマートは部門ごとにカスタマイズされています。
データマートのソースは、部門ごとに構造化されたデータウェアハウスです。
データマートは柔軟性があります。
エンタープライズウェアハウス
エンタープライズウェアハウスは、組織全体にまたがるすべての情報と主題を収集します
これにより、企業全体のデータ統合が可能になります。
データは、運用システムと外部情報プロバイダーから統合されます。
この情報は、数ギガバイトから数百ギガバイト、テラバイト、またはそれ以上までさまざまです。
ロードマネージャー
このコンポーネントは、プロセスの抽出とロードに必要な操作を実行します。
ロードマネージャーのサイズと複雑さは、データウェアハウスごとに特定のソリューション間で異なります。
ロードマネージャーアーキテクチャ
ロードマネージャは次の機能を実行します-
ソースシステムからデータを抽出します。
抽出したデータを一時データストアに高速ロードします。
データウェアハウスと同様の構造への単純な変換を実行します。
ソースからデータを抽出する
データは、運用データベースまたは外部情報プロバイダーから抽出されます。ゲートウェイは、データを抽出するために使用されるアプリケーションプログラムです。基盤となるDBMSでサポートされており、クライアントプログラムがSQLを生成してサーバーで実行できるようにします。ゲートウェイの例としては、Open Database Connection（ODBC）、Java Database Connection（JDBC）があります。
高速ロード
合計ロードウィンドウを最小化するには、データを可能な限り速い時間でウェアハウスにロードする必要があります。
変換はデータ処理の速度に影響します。
変換とチェックを適用する前に、データをリレーショナルデータベースにロードする方が効果的です。
ゲートウェイテクノロジーは、大量のデータが関係する場合にパフォーマンスが低下する傾向があるため、適切ではないことが判明しています。
単純な変換
ロード中に、単純な変換を実行する必要がある場合があります。これが完了すると、複雑なチェックを実行できるようになります。EPOS販売トランザクションをロードしていると仮定して、次のチェックを実行する必要があります。
- 倉庫内で不要なすべての列を取り除きます。
- すべての値を必要なデータ型に変換します。
倉庫マネージャー
倉庫管理者は、倉庫管理プロセスを担当します。これは、サードパーティのシステムソフトウェア、Cプログラム、およびシェルスクリプトで構成されています。
倉庫管理者の規模と複雑さは、特定のソリューションによって異なります。
WarehouseManagerアーキテクチャ
倉庫管理者には以下が含まれます-
- 制御プロセス
- ストアドプロシージャまたはCwith SQL
- バックアップ/リカバリツール
- SQLスクリプト
WarehouseManagerによって実行される操作
倉庫管理者はデータを分析して、整合性と参照整合性のチェックを実行します。
ベースデータに対してインデックス、ビジネスビュー、パーティションビューを作成します。
新しい集計を生成し、既存の集計を更新します。正規化を生成します。
ソースデータを変換して、公開されたデータウェアハウスにマージします。
データウェアハウスのデータをバックアップします。
キャプチャされた寿命の終わりに達したデータをアーカイブします。
Note −倉庫マネージャーは、クエリプロファイルも分析して、インデックスと集計が適切かどうかを判断します。
クエリマネージャー
クエリマネージャは、クエリを適切なテーブルに送信する責任があります。
クエリを適切なテーブルに送信することで、クエリと応答の生成の速度を上げることができます。
クエリマネージャは、ユーザーが提示したクエリの実行をスケジュールする責任があります。
クエリマネージャアーキテクチャ
次のスクリーンショットは、クエリマネージャーのアーキテクチャを示しています。これには次のものが含まれます。
- CツールまたはRDBMSを介したクエリリダイレクト
- ストアドプロシージャ
- クエリ管理ツール
- CツールまたはRDBMSを介したクエリスケジューリング
- サードパーティソフトウェアを介したクエリスケジューリング
詳細な情報
詳細情報はオンラインで保持されるのではなく、次のレベルの詳細に集約されてからテープにアーカイブされます。データウェアハウスの詳細情報部分は、スターフレークスキーマに詳細情報を保持します。集約されたデータを補足するために、詳細情報がデータウェアハウスにロードされます。
次の図は、詳細情報が保存されている場所とその使用方法を図で示しています。
Note −ディスクストレージを最小限に抑えるために詳細情報をオフラインで保持する場合は、アーカイブする前に、データが抽出され、クリーンアップされ、スターフレークスキーマに変換されていることを確認する必要があります。
要約情報
概要情報は、事前定義された集計を格納するデータウェアハウスの一部です。これらの集計は、倉庫マネージャーによって生成されます。要約情報は一時的なものとして扱う必要があります。変化するクエリプロファイルに対応するために、外出先で変化します。
要約情報についての注意点は以下のとおりです。
要約情報は、一般的なクエリのパフォーマンスを高速化します。
運用コストが増加します。
新しいデータがデータウェアハウスにロードされるたびに更新する必要があります。
詳細情報から新たに生成できるため、バックアップされていない可能性があります。