私がこの問題について考え始めたのは、私が作業を依頼されたシステムが完全にビューに基づいたキューブを持っていることに気付いた後です。これらのビューはすべて他のテーブル/ビューに結合されており、ビューにもロジックがコード化されていることに気付きました (if、case ステートメント、convert ステートメント、連結など)。これはすべて私には恐ろしいことのように思えましたが、キューブのデータソースをビューに基づいて作成する必要があるかどうか疑問に思いました。
私にとっては、テーブルの方が理にかなっています。これにより、データソースでの高価な結合が防止され、ビューによって実行される変換が原因で発生する可能性のあるエラーが発生しにくくなります。ただし、ビューをキューブのデータソースとして使用している人はまだ多くいます。ここにベストプラクティスはありますか? ビューをデータソースとして使用したときに得られるいくつかの利点が欠けているのではないでしょうか?
ビューは、SSAS をテーブルから隔離するための重要なレイヤーです。不要な行からではなく、列の変更からではありません。ビューがない場合、SSAS は常にテーブル内のすべての行を処理します。これの典型的なケースは、キューブが「現在の」行のみを必要とする SCD タイプ 2 行のディメンション テーブルです。その他の一般的なケースは、テスト データを制限したり、SSAS パーティションをフィードしたりする場合です。
これらのビューはシンプルに保つのが最適です。つまり、複雑な結合、CTE、計算列などはありません。これらの要件は ETL レイヤーで対処するのが最適です。SSAS レイヤーでのテスト/デバッグ/サポートは困難です。
ビューではなくテーブルからキューブを構築する場合、どのようにしてデータをテーブルに取り込みますか? 最も論理的な方法は、ビューからテーブルをロードすることです。いずれにせよ、それがビューであろうと ETL プロセスであろうと、テーブルにデータを入力するためのビジネス ロジック レイヤーが必要です。
これは、特定の時点でデータをテーブルに「スナップショット」することを意味します。これは、キューブを作成した時点でデータが古くなっている可能性があることを意味します。
それは本当にパフォーマンスの問題です。次の状況では、テーブル (またはインデックス付きビュー) をキューブ ソースとして作成すると便利な場合があります。
ビューを使用してキューブをフィードするだけである場合 (詳細なドリル スルーは使用しない場合) は、ビューからキューブを構築するときにパフォーマンス ヒットが 1 回しか発生しないため、最初にテーブルを構築するときにパフォーマンス ヒットが 1 回発生するよりも、おそらくビューを使用したほうがよいでしょう。ビュー、そして別の (確かに少ない) テーブルからキューブを構築します。
いいえ、速くも遅くもありません。
テーブルではなくビューからキューブを構築するのが通常の方法です。
基礎となるテーブルへの変更に対して、ある程度の隔離を提供します。これにより、基になるテーブルとは異なる方法で情報をグループ化する設計が可能になります。これにより、非正規化が発生します。いくつかの理由があります。
たとえば、キューブにサービスを提供するためだけに存在するビューの列名を簡単に変更できます。さらに、テーブルで指定された名前ではなく、キューブのドメインをモデル化するように、ビューの列に名前を付けることができます。