私の最初のSSASプロジェクトにゼロから取り組み、いくつかのガイダンスを期待しています. データをキューブに取り込むためのさまざまなアプローチを見てきましたが、あるとすればどれが好ましいか疑問に思っています。
私が行った例のほとんどは、特定のデータベース内のテーブル/スキーマ (たとえば、7 つまたは 8 つの特定の販売関連テーブル) を指し示し、メジャーとディメンションを定義し、それらに基づいて処理するだけです。ただし、1 つ以上の SP を実行して、7 つまたは 8 つの販売関連テーブルのデータを、必要なファクト テーブルにより近い 1 つまたは 2 つのテーブルにコンパイルする実稼働システムもいくつか見てきました。次に、キューブ データ ビューはこれらに基づいています。
推奨される特定のアプローチなどはありますか？
前もって感謝します。
通常、sp-s または SSIS で構築されたある種の ETL (抽出、変換、読み込み) プロセスがあり、ソースから読み取り、操作を行い、専用のデータマート スターのようなスキーマにデータを書き込みます。
このアプローチには利点がありますが、唯一の欠点は、それに伴う労力、時間、およびコストです。たとえば、ETL でデータ品質の問題を処理し、適切な代理ディメンション キー (int キーなど) を割り当て、M2M 関係などをモデル化できます。
そうは言っても、多くのショップが正規化されたスキーマの上にキューブを構築しているのを目にします。あなたが述べたように、これを行うことができます-SSASで複数のテーブルを使用するか、スターのようなスキーマですべてをマッシュアップしてからDSVでそれらのビューを使用し、その後SSASでそれらのビューを使用するビューを作成します。私は通常、概念実証プロジェクト、または正規化されたテーブルに適切な形式のデータが既にあるため、独自のスキーマを構築する必要がないものに対して、このアプローチをお勧めします。
適切な SSAS ソリューションを構築していて、それを行う時間とスキルがある場合は、間違いなく最初のアプローチを選択する必要があります。ただし、これらの要因が多少不確かで、試したり、遊んだりしているだけの場合は、ビューから始めて、後で適切なスキーマに置き換えることができます。このようにして、複雑な ETL を維持する必要なく、その方法を学ぶことができます (つまり、より柔軟になります)。SSAS は特定の形式のデータを優先し、ビューを構築するだけであることに注意してください。または、ストレート テーブルを使用すると多少制約が生じます。必要に応じて、独自のスキーマを作成する必要があります。