現在、SQL Server、SSIS、およびSSASを使用しているデータウェアハウスのファクトおよびディメンション表を設計しています。ディメンションとファクト・テーブルの関係をSQLにプログラミングすると、実際のメリットはありますか？または、キューブを作成する時間が来たときに手動で関係を定義するほうがよいでしょうか？スタースキーマテーブルデザインにリレーションシップを含めることに利点はありますか？
データをテーブルに挿入する際に制約がなく、したがって関係を削除しないと、データをロードして変換する方が簡単なようです。
私は、テーブルに外部キー制約を付ける意味として「関係をプログラミングする」と解釈しています。
いいえ、データウェアハウスでは、ファクト表に主キー制約または外部キー制約を課すべきではありません。
いくつかの問題について言及しましたが、もう1つの問題は、行を挿入するときにこれらの制約によってパフォーマンスのオーバーヘッドが発生し、ETLプロセスのコストが高くなるという問題です。
トランザクションデータベース設計の経験がある人にとっては、これは学習して経験したことのすべてに反するかもしれません。外部キーの制約は、複数のプロセスが同時にデータを変更するデータベースでは不可欠です。開発者の最善の努力にもかかわらず、何らかの理由で2つのプロセスがデータを壊してしまうという明確なリスクがあります。この制約は基本的に重要な安全ネットです。
ディメンション・モデルでは、データベースは、1つのETLプロセスによってのみ、高度に制御された方法で作成されます。これにより、データの破損の危険性が大幅に低下し、制約の余分なコストがそれに値するものではない点が大幅に減少します。
私はFK Constraintsが必要だと思っています。なぜなら、DWへのアップデートは「ほとんど」制御されているからですが、必ずしもそうとは限りません。たとえば、データの問題などが発生した場合に手動によるデータの修正が行われます。 [理想的には起こらないはずですが.... ....]
キーがパフォーマンスに影響を与えないようにするには、ロード前にキーを無効にして再度有効にすることができます。これにより、データが適切であるという確信が得られ、負荷中のパフォーマンスの問題も取り除くことができます。覚えておくべきもう一つのことは、処理時間はほとんどのデータウェアハウスにとって大きな制約ではないということです。
潜在的なデータの完全性の問題を解決するために必要な時間を考慮すると、FKは十分に価値があります。
完璧な回答！ありがとう！ – rrydman