データウェアハウジング-配信プロセス

データウェアハウスは決して静的ではありません。ビジネスが拡大するにつれて進化します。ビジネスが進化するにつれて、その要件は変化し続けるため、これらの変化に対応するようにデータウェアハウスを設計する必要があります。したがって、データウェアハウスシステムには柔軟性が必要です。

理想的には、データウェアハウスを配信する配信プロセスが必要です。ただし、データウェアハウスプロジェクトは通常、さまざまな問題に悩まされており、ウォーターフォール法で要求される厳密かつ秩序立った方法でタスクと成果物を完了することが困難です。ほとんどの場合、要件は完全には理解されていません。アーキテクチャ、設計、およびビルドコンポーネントは、すべての要件を収集して調査した後にのみ完成できます。

配送方法

配信方法は、データウェアハウスの配信に採用された共同アプリケーション開発アプローチの変形です。リスクを最小限に抑えるために、データウェアハウスの配信プロセスを準備しました。ここで説明するアプローチは、全体的な配信時間スケールを短縮するものではありませんが、開発プロセスを通じてビジネス上のメリットが徐々に提供されることを保証します。

注-プロジェクトと配信のリスクを軽減するために、配信プロセスはフェーズに分割されています。

次の図は、配信プロセスの段階を説明しています-

配信方法

IT戦略

データウェアハウスは、利益を生み出すためにビジネスプロセスを必要とする戦略的投資です。プロジェクトの資金を調達して維持するには、IT戦略が必要です。

ビジネスケース

ビジネスケースの目的は、データウェアハウスの使用から得られるビジネス上の利点を見積もることです。これらの利点は定量化できない場合がありますが、予測される利点を明確に述べる必要があります。データウェアハウスに明確なビジネスケースがない場合、ビジネスは配信プロセスのある段階で信頼性の問題に悩まされる傾向があります。したがって、データウェアハウスプロジェクトでは、投資のビジネスケースを理解する必要があります。

教育とプロトタイピング

組織は、データ分析の概念を実験し、ソリューションに落ち着く前にデータウェアハウスを持つことの価値について教育します。これはプロトタイピングによって対処されます。データウェアハウスの実現可能性と利点を理解するのに役立ちます。小規模のプロトタイピング活動は、以下の限り教育プロセスを促進できます-

プロトタイプは、定義された技術目標に対応しています。
プロトタイプは、実現可能性の概念が示された後に廃棄することができます。
このアクティビティは、データウェアハウスの最終的なデータコンテンツの小さなサブセットに対応します。
アクティビティのタイムスケールは重要ではありません。

早期のリリースを作成し、ビジネス上のメリットをもたらすには、次の点に留意する必要があります。

進化できるアーキテクチャを特定します。
ビジネス要件と技術設計図フェーズに焦点を当てます。
最初のビルドフェーズの範囲を、ビジネス上のメリットをもたらす最小限に制限します。
データウェアハウスの短期および中期の要件を理解します。

ビジネス要件

質の高い成果物を提供するには、全体的な要件を確実に理解する必要があります。短期および中期の両方のビジネス要件を理解していれば、短期要件を満たすソリューションを設計できます。その後、短期的なソリューションを完全なソリューションに成長させることができます。

次の側面は、この段階で決定されます-

データに適用されるビジネスルール。
データウェアハウス内の情報の論理モデル。
当面の要件のクエリプロファイル。
このデータを提供するソースシステム。

技術的な青写真

このフェーズでは、長期的な要件を満たすアーキテクチャ全体を提供する必要があります。このフェーズでは、ビジネス上のメリットを得るために短期的に実装する必要があるコンポーネントも提供します。設計図では、以下を識別する必要があります。

全体的なシステムアーキテクチャ。
データ保持ポリシー。
バックアップと復元の戦略。
サーバーおよびデータマートのアーキテクチャ。
ハードウェアとインフラストラクチャの容量計画。
データベース設計のコンポーネント。

バージョンの構築

この段階では、最初の生産成果物が生産されます。この製品は、データウェアハウスの最小コンポーネントです。この最小のコンポーネントはビジネス上の利点を追加します。

履歴ロード

これは、必要な履歴の残りがデータウェアハウスにロードされるフェーズです。この段階では、新しいエンティティは追加しませんが、追加の物理テーブルを作成して、増加したデータボリュームを格納する可能性があります。

例を挙げましょう。ビルドバージョンフェーズが2か月分の履歴を持つ小売販売分析データウェアハウスを提供したとします。この情報により、ユーザーは最近の傾向のみを分析し、短期的な問題に対処できます。この場合、ユーザーは年次および季節的な傾向を特定できません。そのために、過去2年間の販売履歴をアーカイブから読み込むことができます。これで、40GBのデータが400GBに拡張されました。

注意-バックアップとリカバリの手順は複雑になる可能性があるため、別のフェーズでこのアクティビティを実行することをお勧めします。

アドホッククエリ

このフェーズでは、データウェアハウスの運用に使用されるアドホッククエリツールを構成します。これらのツールは、データベースクエリを生成できます。

注意-データベースが大幅に変更されている場合、これらのアクセスツールを使用しないことをお勧めします。

オートメーション

このフェーズでは、運用管理プロセスが完全に自動化されています。これらは含まれます-

データを分析に適した形式に変換します。
クエリプロファイルを監視し、システムパフォーマンスを維持するための適切な集計を決定します。
異なるソースシステムからのデータの抽出とロード。
データウェアハウス内の事前定義された定義から集計を生成します。
データのバックアップ、復元、およびアーカイブ。

スコープの拡大

このフェーズでは、データウェアハウスが拡張され、ビジネス要件の新しいセットに対応します。スコープは2つの方法で拡張することができます-

追加のデータをデータウェアハウスにロードする。
既存の情報を使用して新しいデータマートを導入する。

注-このフェーズはかなりの労力と複雑さを伴うため、個別に実行する必要があります。

要件の進化

配信プロセスの観点から、要件は常に変更可能です。それらは静的ではありません。配信プロセスはこれをサポートし、これらの変更がシステム内に反映されるようにする必要があります。

この問題は、既存のクエリのデータ要件とは対照的に、ビジネスプロセス内のデータの使用に関するデータウェアハウスを設計することで対処されています。

アーキテクチャは、ビジネスニーズに合わせて変更および成長するように設計されており、プロセスは疑似アプリケーション開発プロセスとして動作します。このプロセスでは、新しい要件が開発アクティビティに継続的に供給され、部分的な成果物が生成されます。これらの部分的な成果物はユーザーにフィードバックされた後、ビジネスニーズに合わせてシステム全体が継続的に更新されるように修正されます。

Dwh-delivery-process

目次