IISログを集約し、それらに対して簡単なクエリをすばやく実行できるようにしたいと思います（たとえば、過去1か月にページxがヒットした回数など）。
このデータ（おそらく時間ディメンションで10分程度の粒度）をSSASキューブに集約したいと思います。
すでにSSISを介してログをテーブルにインポートしています。テーブルが非常に大きくなっているので、キューブ内の履歴を保持しながら（3か月以上前など）、古いデータの削除を開始したいと思います（したがって、3か月以上にわたってクエリを実行できます）。これは合理的なことですか？明らかに、キューブを変更したい場合、キューブを簡単に再構築することはできません...そして、データベースであるかのようにキューブのバックアップを開始する必要があると思いますか？
現在、データにPKがありません-ID列を追加するか、日付、時刻、およびURLが古い複合PKを作成する方がよいでしょうか？
これをうまく実装した誰かからのフィードバックは素晴らしいでしょう:)
ありがとう！
私はこれを正確に行っていませんが、私ができる限り多くのことについてあなたに意見を述べます：
テーブルが大きくなるのに、なぜこれが問題になるのですか？それはストレージスペースですか、それとも速度ですか？
速度が速い場合は、テーブルのパーティション分割を使用して大きなテーブルを分割することを検討してください。それらを日付範囲でパーティション化してから、パーティションを別のテーブルに切り替えることができます（元のテーブルのサイズを縮小します）。これは純粋なメタデータ操作であり、即座に実行されます。SSASは、再構築が必要になった場合に、処理時に両方のテーブルを結合するビューを使用できます。
ストレージスペースの場合、SQL Serverでの圧縮を確認しましたか（2008年に利用可能ですが、使用しているバージョンがわかりませんか？）。
個人的には、キューブを再構築する機能がなければ満足できません-また、キューブはソースデータ（またはDSVに従って使用する部分）のコピーを作成するため、思ったほど保存できない可能性があることを忘れないでください古いデータを削除し、キューブを「ストレージデバイス」として扱う場合。キューブはテーブルの一部のみを使用しますか？基になるデータと比較してどのくらいのサイズですか？
SSASではデータのPKは厳密には必要ありません-しかし-私は常にそれらを使用して、主に重複ロードを防止します（また、時間ごとにロードします-データが最後にロードされたものよりも新しいことを確認します）が、重複ロードを防止するPK制約があると便利です。
PKの場合、日付、時刻、URLは適切に聞こえますが、サイトの混雑具合によって異なります。あなたの例では、2人が同じURLを同じ秒で表示することはできません。PKにIPアドレスを追加できますか？訪問者がすぐにリフレッシュした場合はどうなりますか？それを重複として扱い、SSISデータフローから削除しますか？
幸運を祈ります。私が言ったことについて質問があれば教えてください。