私はビジネスインテリジェンスに不慣れです。
私は、BIモジュールを実装して、Webソリューションを完成させるために会社に雇われました。たくさん読んだ後、私はBIプロセスがどのように見えるかについてのアイデアを得ることができたと思います。あなたは、BIプロセスについての私のアイデアを同封していることがわかります。
これがすべてのワークフローの正しいビジョンであるかどうかを教えてください。そうでない場合は私を訂正してください。別の質問ですが、スキーマ内のデータマイニングの場所がわかりません。必要に応じて、どこで使用すればよいですか？
どうもありがとう、
以下はあなたが考慮したいと思うかもしれないいくつかのポイントです：
プレゼンテーション層がExcelまたはWebサービスのいずれかであり、他には何もないというのは正しいですか？SSRS、Cognos、Business Objects、MicrostrategyなどのWebレポートプラットフォームを展開したい場合はどうなりますか？これらのプラットフォームは通常、Webサービスなしでデータに直接アクセスします。
フラットファイルとダウンストリームデータベースに追加のデータを出力する必要がある場合があります。データは、OLAPキューブまたは生のソースデータのいずれかに基づいている場合があります。したがって、これらをメインデータウェアハウスレベルおよびOLAPレベルの宛先として含めることができます。
Webプレゼンテーション層を実装する場合、それはOLAPキューブ上にあるだけではない可能性があります。OLAPキューブに含まれていないデータについてレポートするリクエストを受け取る可能性があり、いくつかのレポートをサポートするためだけに追加する価値はない場合があります。この場合、メインのデータウェアハウスがOLAPだけでなくWebレポートプラットフォームのソースになる可能性があることに注意してください。
データマートには通常、集約されたデータは含まれていません。通常、詳細レベルのデータが含まれています。OLAPキューブは詳細データに対して集計を実行しますが、基になるデータマート自体にはトランザクションレベルのファクトが含まれています。
WebサービスなどのETLプロセスによってインポートされる追加のデータソースを持つことができます。また、複数のデータマートとOLAPキューブが存在する可能性があることを強調したのと同じように、複数のデータベースとフラットファイルがあることを強調することもできます。
OLAPキューブ用に個別のデータマートは必ずしも必要ではありません。1つの中央データウェアハウスを構築している場合は、1つの中央OLAPキューブを作成し、キューブのセキュリティロールに基づいてデータのディメンションとスライスへのアクセスを制限できる場合があります。
データウェアハウスをロードする前に、ステージングデータベースをロードする必要があることを示すことができます。そうではないかもしれませんが、一般的には、データウェアハウスにマージする前にロードする場所を確保するために、別のステージングデータベースを用意することをお勧めします。一部のETLプロセスは、途中でマージできるため、データウェアハウスに直接入ることができますが、最終的な宛先にマージする前に、ステージングデータベースにデータをロードすることがおそらく理にかなっている場合がたくさんあります。これは、ETL /ストアドプロシージャは、宛先またはオブジェクトよりもデータを移動するためのメソッドであるため、おそらくダイアグラム内で独自のエンティティである必要があることを意味します。ダイアグラムを見ると、すべてのエンティティは実際のオブジェクトであり、MDXのようなプロセスではありません。
ETLプロセスを介してデータがデータマートにロードされていることを示すことができます。ETLは、データウェアハウスをロードするだけでなく、任意の段階でデータを移動することを目的としています。キューブを処理する場合でも、ETLプロセスが必要です。
OLAPサーバーは、必ずしも別の物理サーバー上にある必要はありません。データベースサーバー上のサービスである可能性があります。スケールアップまたはスケールアウトによってパフォーマンスの問題に取り組むかどうか、または地理的なパフォーマンスの問題のためにキューブを複数のOLAPサーバーに公開するかどうかによって異なります。