意見を求める：SSRSレポートのパフォーマンスを向上させるための非正規化のファクトテーブルとディムテーブル

Question

私たちのチームのディスカッションポイントについては、少し議論の余地があるようです。 Microsoft SQL Server 2012プラットフォームのデータウェアハウスに取り組んでいます。私たちはこのデータウェアハウスを構築するためにKimball Architectureに従ってきました。

問題：事実と薄暗いテーブルからデータを調達する際、この倉庫からデータをソース（SSRS上に構築された）

レポーティングソリューションは、大幅なパフォーマンスの問題があります。私たちのチームメンバーの中には、事実からデータを抽出し、SSISパッケージを使用して新しいテーブルセットに暗くすることを提案している人もいます。これは、これらのテーブルを「スナップショット」テーブルに非正規化することを意味します。このようにして、これらのテーブルを結合してレポート内にデータセットを作成する必要はありません。これらのテーブルから直接データを読み取ることができます。

私はこれについて自分の心配があります。矛盾、異なるデータ構造のメンテナンス、データの複製などがあります。

質問：

は、あなたがテーブルに適切なアプローチを報告するために（事実と薄暗いテーブルをdenormalisingで）スナップショット表を作成することを検討しますか？

あなたの意見をお聞きしたいと思います。

乾杯 私のアドバイスは、常にあなたのテーブルを非正規化し、1回のファクト表と各次元（スタースキーマ）ごとに1つのテーブルを持ってしようとするだろう、生キューブのパフォーマンスのためのニシン

Answer 1

スナップショットテーブルに問題がないとは思わない。データウェアハウスの最も重要な2つの側面は次のとおりです。

1. データは正しいです。
2. このデータは有用です。

ユーザーが必要な合計を抽出できない場合は、合理的なタイムスケールで倉庫を使用しません。

独自のソリューションには、3つのスナップショットテーブルが含まれています。あなたのように、私は不一致を心配していました。これに対処するため、私たちは自動チェックプロセスを構築しました。このサブシステムは、ネットワークドライブに格納された一連のクエリを1時間に1回実行します。クエリによって返されたレコードはすべて失敗とみなされます。不合格が報告され、すぐに私のETLチームによって調査されます。このサブシステムは、スナップショットと基礎となる事実が常に整合し、互いに一致することを保証します。ドリフトが防止されます。

つまり、追加のテーブルは複雑さになります。そしてそれには、管理に多くの時間と労力が必要です。あなたの倉庫に別のレイヤーを導入する前に、これらのクエリーがなぜ成果の下がっているのかを調べるべきです。結合が非難される場合：

1. P/Fキーに不適切なデータ型を使用していますか？
2. FKeysは索引付けされていますか（一部のRDBMSではこれがデフォルトで行われていますが、そうでないものもあります）。
3. 違反しているクエリの実行計画を見ましたか？
4. ジョインは本当に責任があるのですか、それともdimテーブルに適用されるフィルタですか？

Answer 2

。 実際に役立つかどうかわからない場合は、マテリアライズド・ビューの作成を開始できます。これらは両方の世界の中で最高のものですが、長期的にはあなたのetlを変えるべきです。 私の以前の仕事では、かなりうまく機能するテーブルを平坦化しただけでした。私たちは正規化されたスキーマを持っていますが、最後のステップでそれを平坦化します。