スタースキーマテーブルの設計に関係を含めることには利点がありますか？

Question

現在SQL Server、SSIS、およびSSASを使用しているデータウェアハウスのファクトテーブルとディメンションテーブルを設計しています。ディメンションとファクトテーブルの間の関係をSQLにプログラミングすることで、実際のメリットを得ることができますか？または、キューブを作成するときが来たら、手動でリレーションシップを定義する方が良いでしょうか？

テーブルへのデータの挿入に制約がなく、そのためリレーションシップを除外している場合、データのロードと変換が簡単になります。

Answer 1

「関係のプログラミング」を解釈しています。テーブルに外部キー制約を設定する意味として。

いいえ、データウェアハウスでは、ファクトテーブルに主キーまたは外部キーの制約を課すべきではありません。

いくつかの問題に言及しましたが、別の問題は、これらの制約により行の挿入時にパフォーマンスのオーバーヘッドが発生し、ETLプロセスがより高価になることです。

トランザクションデータベースの設計のみを経験した人にとって、これは彼らが学んだことや経験したことすべてに反する可能性があります。外部キー制約は、データを同時に変更する複数のプロセスがあるデータベースにとって不可欠です。開発者の最善の努力にもかかわらず、2つのプロセスが何らかの形でデータを台無しにするという明確なリスクがあります。制約は基本的に重要なセーフティネットです。

ディメンションモデルでは、データベースは1つのETLプロセスによってのみ、高度に制御された方法で作成されます。これにより、データが破損するリスクが大幅に減少し、制約の追加コストには価値がなくなります。

Answer 2

DWの更新は「ほとんど」制御されていますが、常にではないため、FK制約が必要だと思います。たとえば、データの問題などが発生した場合、手動でデータを修正します。 [理想的にはこれは起こらないはずですが、.......：）]

キーがパフォーマンスに影響を与えないようにするために、ロードする前にキーを無効にし、再度有効にすることができます。これにより、データが正しいという確信が得られ、ロード中のパフォーマンスの問題も取り除かれます。覚えておくべきもう1つのことは、処理時間はほとんどのデータウェアハウスにとって大きな制約ではないということです。

潜在的なデータの整合性の問題を修正するために必要な時間を考慮する場合、FKを持つことは十分に価値があります。