ステップ 1: ビジネス・プロセス要件を特定する

ディメンション・モデルを設計する対象のビジネス・プロセスを選択します。 選択内容に基づいて、ビジネス・プロセスの要件が収集されます。 1 つのビジネス・プロセスに、複数のディメンション・モデルが必要です。

ディメンション・モデリングにおいて最もふさわしい分析単位は、組織が最も注目するビジネス・プロセスです。 ビジネス・プロセスとは、関連するアクティビティーの集まりです。 ビジネス・プロセスは、ビジネスの関心の対象であるトピックによって分類されます。 可能性の高いビジネス・プロセスの候補リストを作成する場合、要件に優先順位を付ける必要があります。 ビジネス・プロセスの例には、顧客、利益、販売額、組織、および製品があります。

ビジネス・プロセスは常にビジネス部門であるとは限りません。 例えば、営業部門とマーケティング部門が注文データにアクセスするシナリオを考察してみましょう。 この場合、営業部門とマーケティング部門用に別々のディメンション・モデルを作成するのではなく、注文データを処理する 1 つのディメンション・モデルを作成します。 各部門別にディメンション・モデルを作成すると、重複データを保管することになります。 重複、つまりデータの冗長性は、データの品質やデータの一貫性に関する多数の問題点をもたらす可能性があります。

(社内に存在するすべてのビジネス・プロセス候補の中から) 1 つのビジネス・プロセスを選択する場合、特定の基準に従ってビジネス・プロセスに優先順位を付ける必要があります。 基準としては、ビジネス・プロセスの重要度、ソース・システムにおけるデータの品質、ビジネス・プロセスの実現可能性と複雑さなどが挙げられます。

ディメンション・モデルのビジネス・プロセスを特定する場合、次のメタデータを収集します。
通常、ディメンション・モデルは、データウェアハウスおよび OLTP システムという 2 つの環境で使用されます。
データウェアハウスとディメンション・モデル
データウェアハウス内のデータをパーティション化する場合、サブジェクト・エリアに基づいてデータを分割します。 データウェアハウスはサブジェクト指向です。 データウェアハウスには、顧客や製品などの、組織内の特定の選択されたサブジェクト・エリアが含まれます。 データウェアハウスを実用的に実装するために、最も重要なデータは特定のビジネス・プロセスに含まれています。 この要件は、OLTP の要件とはかなり異なります。

データウェアハウス環境での照会は、本来戦略的であり、広範囲に関わる質問が出されます。 照会の例には、「どの製品がよく売れるか?」や「最も営業成績の振るわない販売営業所はどこか?」などがあります。 このような照会に回答するために、データウェアハウスは、製品または組織などのサブジェクト・エリアを中心に構築されます。 これらのサブジェクト・エリアは、データウェアハウスの最も代表的な論理パーティション単位です。

OLTP システムとディメンション・モデル
運用環境は、特定の機能セットを実行する、トランザクション指向のアプリケーションを軸にして構築されているため、運用環境ではアプリケーションまたは機能別にデータをパーティション化します。。 運用環境の目標は、それらの機能をできるだけ迅速に実行することにあります。 運用環境で実行される照会がある場合、それらは本来限定的で、その時点に関する質問に答えるものでなければなりません。 「スミス氏が発行した小切手は処理済みですか?」という質問は、照会の一例です。

企業のビジネス・プロセス・リストを作成して調査する

企業全体のすべてのビジネス・プロセスのリストを作成します。 リストの作成時には、以下の評価要素を考慮します。
ヒント: 各評価要素およびビジネス・プロセスに値を割り当てると、役に立ちます。 値を割り当てるときには、各ビジネス・プロセスの優先順位を判断できます。

モデル化するビジネス・プロセスを特定する

ビジネス・プロセスに優先順位を付けます。 ディメンション・モデルの作成時には、具体性の最も高いプロセスと最も低いプロセスを特定する必要があります。 このステップは、上記で決定した評価要素をまとめる作業です。 ビジネスにとって最も重要なプロセスを最初にモデル化する必要があります。

いくつかのプロセスに共通な上位のエンティティーおよび手段を特定する

各プロセスに関連する上位のビジネス・エンティティーを特定します。 いくつかのビジネス・プロセスに共通するエンティティーはどれかを特定します。 共通するエンティティーを特定すると、その共通 (共有) ディメンションを介してビジネス・プロセスを 1 つにまとめることができます。

企業全体で使用する共有ディメンションを作成するには、ビジネスのさまざまな部分が、その共通エンティティーの定義に合意する必要があります。 ビジネスの各部門によって共通エンティティーの定義も異なるため、このプロセスには時間がかかることがあります。 後日定義を変更する必要が生じた場合、既存のアプリケーションが影響を受ける可能性があるため、共通エンティティーは早い段階で定義する必要があります。

データウェアハウスは、似たような情報を要求する照会に対して、一貫した情報を提供する必要があります。 一貫性を維持する方法の 1 つに、データウェアハウス内のすべてのアプリケーションとデータマート (ディメンション・モデル) で共有および使用するディメンション表を作成する方法があります。 共有ディメンションとして考えられるのは、顧客、時刻、製品、地理的ディメンション (例えば店舗ディメンション) などです。

一連の共有ディメンションの開発は、簡単な作業ではありません。 複数のビジネス・プロセスに共通なあらゆるディメンションは、同じ方法でディメンション情報を表していなければなりません。 つまり、情報とその基となるデータが共有されている必要があります。 通常各ビジネス・プロセスは、ファクト表、いくつかの共有ディメンション表、およびそのビジネス機能に固有なディメンション表を含む、独自のスキーマを持ちます。

データ・ソースを特定する

ビジネス・プロセスに関係するデータ・ソースを特定します。 ディメンション・モデルは、以下のいずれかのソースから作成されます。
  • 企業全体のデータウェアハウス
  • OLTP ソース・システム (独立または従属したデータマート・アーキテクチャーの場合)
  • 独立したデータマート (この場合、独立したデータマートを別のデータマートまたはデータウェアハウスに統合しても構いません)

要件の収集方法を選択する

要件の定義は、一般的に容易ではありません。 通常、結果を見てはじめて、その結果が要件を満たすか満たさないかを判別できます。 また、組織の要件も、時間の経過とともに変わります。 今日有効であったものが、翌日には有効でなくなる可能性もあります。 にもかかわらず、開発サイクルのこの時点で特定した要件を使用して、ディメンション・モデルを構築します。

疑問点は以下のとおりです。
  • 正確に定義できないものをどうやって構築できるのか?
  • 要件を特定できたとどうやって判断するのか?
決定的なテスト方法はありませんが、通常は、要件が以下の質問への回答を満たしていれば、モデル化プロセスを開始できます。
要件をすべて収集するには、以下の質問を検討する必要があります。
  • 対象とする人物、グループ、および組織は?
  • どの機能を分析する必要があるか?
  • なぜそのデータが必要なのか?
  • いつそのデータを記録する必要があるか?
  • 関連プロセスが発生する地理的および組織的な場所はどこか?
  • 機能のパフォーマンスはどのように測定されるか?
  • ビジネス・プロセスのパフォーマンスはどのように測定されるか? 成功または失敗を決定する要素は何か?
  • 情報の配布方法は? それは、データ・レポート、印刷物、E メール、または別の方法か?
  • 分析および意思決定にどのようなタイプの情報が不足しているか?
  • 情報のギャップを埋めるために、現在どのようなステップがとられているか?
  • どの程度詳細であれば、データ分析が可能か?
一般的に、ビジネス要件の抽出方法のほとんどは、ソース主導型とユーザー主導型のどちらかのアプローチに分類されます。
ソース主導型
ソース主導型の要件収集では、稼動中の運用システムのソース・データを使用して要件を定義します。 ソース・データ・モデルが使用可能な場合はそれを分析するか、または実際の物理レコード・レイアウトから目的のデータを選択して分析することにより、要件を定義することができます。

この方法の主な利点は、この時点で利用可能なデータに限定しているため、すべてのデータを供給できることが最初からわかっている点です。 2 つ目の利点は、プロジェクトの初期の段階でユーザーが要する時間を最小限にできる点にあります。 ただし、ユーザーが関わる場合に得られる重要性と価値に取って代わるものはありません。

当然、この方法には次のような欠点もあります。
  • ユーザーの関与を最小限にすることで、間違った要件セットを作成するリスクが増大します。
  • ソース・データの量と、そのデータに対するソース・モデルの有無によっては、非常に時間のかかる方法でもあります。
  • 一部のユーザーは、現在は使用できないデータにアクセスする必要がある可能性があります。
すべての要件を特定する機会がなければ、外部データのを取得に何が必要かを調査する機会もなくなります。 外部データとは、企業外部に存在するデータのことです。 外部にあっても、外部データは多くの場合ビジネス・ユーザーにとって重要な価値があります。
ソース主導型の方法では、手元にあるデータが提供されます。これは、少なくとも以下の 2 つのケースに適しています。
  • この方法を使用して、企業の関心対象の主要なディメンションの、かなり包括的なリストを作成できます。 企業全体のデータウェアハウスを作成しようとしている場合、個別に開発されたデータマート間で重複するディメンションの増加を最小限にすることができます。
  • ソース・データ内の関係を分析することにより、データウェアハウスの開発で注力する領域を特定できます。
ユーザー主導型
ユーザー主導型の要件収集では、ユーザーが実行する機能を調査することで、要件を定義します。 通常は、ユーザーとの一連の会議またはインタビューを通じて行います。

この方法の主な利点は、使用可能な情報ではなく、本当に必要な情報を提供することに焦点が当たる点です。 一般的にこの方法は、ソース主導型の方法よりも範囲は狭くなります。 したがって、ユーザー主導型の方法では、一般的に、より短い期間で有用なデータウェアハウスやデータマートが作成されます。

ただし、ユーザーの期待はきめ細かく管理する必要があります。 ユーザーは、必要とするデータの一部は、さまざまな理由で利用できない可能性もあることを明確に理解する必要があります。 ただし、ユーザーが必要とする情報に限定すべきではありません。 データウェアハウスの要件を定義する際には、別の考え方も奨励する必要があります。 これは、ある要件を、利用可能でないであろうというだけの理由で除外することを防止します。 あるユーザーが焦点をしぼり過ぎていた場合、実動システムで使用可能な有用なデータを見逃す可能性があります。

ユーザー主導型の要件収集は、特に従属するデータマートの開発時や、ビジネス全体にまたがる企業ウェアハウスからデータマートにデータを取り込むする場合、適した方法でです。

要件を収集する

要件を収集する際には、ビジネス・ユーザーのニーズを収集して文書化します。 要件を収集する際には、ユーザーが関与するビジネス・プロセスおよび情報分析アクティビティーを調査します。 ユーザーは、通常、ビジネスのある側面を評価または分析する必要があります。 ビジネス・ユーザーが日々関与する以下の 2 つの主要な分析要素の収集に力を注いでください。
要件を収集するときは、モデル化を行う問題領域を理解するよう努める必要があります。 通常、この段階での要件は正式には文書化されず、スキーマの詳細も完全ではありません。 上記の要件を収集する場合、以下の関心領域を特定します。
  • ビジネスが取り組む必要のある最も重要な課題。 各課題に重要度の値を割り当てて、取り組むべき最も重要な課題を判別することができます。
  • データの変化に伴って、ビジネスでそのデータをどのように記録する必要があるか。 例えば、製造中止になった製品の履歴データや社員記録などを管理する方法を知る必要があるかもしれません。

要件を分析する

ビジネス要件を分析します。 非公式の要件を決定し、上位のメジャーとエンティティーをセットアップします。 これらのオブジェクトは、データをモデリングする際のディメンションとなる可能性があります。 このドラフトから開始し、下位のエンティティーおよびメジャーへと進めていきます。 データ・モデルの各パーツごとに、ディメンション、階層、およびメジャーのドラフトを作成することで、要件の構造のドラフト作成を開始できます。

ビジネス・プロセスの分析を要約する

分析に基づいて、レポートを作成します。 レポートには、次の情報が含まれている必要があります。

フィードバック