毎日、データベースに約 150,000 行のデータが書き込まれています。これらの行は、たとえば発信記事を表します。ここで、 SSRSを使用して、1 日あたりの平均記事数を経時的に示すグラフを表示する必要があります。また、昨日の実際の記事数に関する情報も必要です。
アイデアは、すべてのトランザクションを集約して表示し、何かが間違っていることを示すことができるものを用意することです (たとえば、平均よりも 20% 少ない記事を送信するなど)。
私の考えは、昨日のデータを毎晩SSASに移動し、そこにトランザクション数の集計値と昨日のデータからの実際のトランザクション数を格納することです。SSAS を使用すると、レポートが高速化されることが期待されます。
これは正しい考えだと思いますか。SSAS をスキップして、生データを直接レポートする必要がありますか? 標準の SQL クエリを使用して生データに対してレポート サービスを使用する方法は知っていますが、SSAS をクエリする場合、これはどのように変化しますか? SSASがわかりません- どこから始めればよいでしょうか ..?
SSAS の優れた点は、計算されたメジャーを作成するか、KPI を使用することによって、非常に簡単に話題になっている指標を取得できることです。
私はMicrosoft SQL Server 2005 によるビジネス インテリジェンスの提供から始めました。良い紹介がありましたが、残念ながら詳細になると冗長すぎます。しかし、このフレームワークを使用して SSAS、OLAP、およびレポートを理解したい場合は、これが良い出発点です。
Mosha Pasumansky は、SSAS とMDXに関するブログを作成しており、優れたリンクが掲載されています。
それ以外では、マイクロソフトのオンライン ブックをお勧めします。
SSAS (分析サービス) と SSIS (統合サービス) を混同していませんか?
SSAS は ETL ではなく、OLAP ツールです。
SSIS は ETL ツールです。
私はローワンが言ったことすべてに同意します。私はちょうど条件に混乱しています。
@セルジオと@ローワン
はい、データをデータベースにロードして変換することについて話しているわけではありません (SSIS ツールのように)。これは、当社の統合プラットフォームを使用して解決されます。
SSAS はETLツールです。基本的に、どこかからデータを取得し (発信記事)、何かを実行し (集計)、別の場所 (集計テーブル、データ ウェアハウスなど) に配置します。詳細はリンク先をご確認ください。
おそらく、すべての行を DB に無期限に保持することはありません。より長いトレンドをレポートできるようにしたい場合は、いずれにせよ履歴データの何らかの集計を行う必要があります。したがって、レポートでこの履歴データ ストアをソースとして使用することは理にかなっています。その後、それを使用して、あらゆる種類の派手なレポートを作成できます。
TL;DR: 将来のレポートのニーズを念頭に置いて、集計履歴テーブルを定義してください。SSAS を使用してテーブルにデータを入力し、毎日の更新から更新します。そのテーブルから報告します。詳細情報: スター スキーマとデータ ウェアハウス。
@Riri多分SSASは、あなたが提示した状況ではやり過ぎです。集計テーブルを毎日作成するだけでよい場合は、SQL Server で通常の JOB を作成し、それを通常の T-SQL スクリプトで実行することで実現できます。
私は、毎日のプロセスでこのアプローチを数年間使用して、1 日あたり約 9 GB の新しいデータからビジネス指標を計算してきました。機能し、高速で、シンプルで、使い慣れたテクノロジーを使用します。日常のプロセスがより複雑になった場合 (ファイルから読み取り、FTP を使用し、電子メールを送信する必要がある場合)、SSIS パッケージ (または任意の他の ETL ツール) に移行できますが、OLAP を提供する必要がない限り、SSAS の使用はお勧めしません。ユーザーに機能を提供します。