現在 SQL Server、SSIS、および SSAS を使用しているデータ ウェアハウスのファクト テーブルとディメンション テーブルを設計しています。ディメンションとファクト テーブル間のリレーションシップを SQL にプログラミングすることで、実際にメリットが得られるでしょうか? それとも、キューブを作成するときにリレーションシップを手動で定義したほうがよいのでしょうか?
テーブルへのデータの挿入に制約がなく、関係を除外すると、データのロードと変換が簡単になるようです。
質問する
318 次
2 に答える
6
「リレーションシップのプログラミング」を、テーブルに外部キー制約を設定する意味として解釈しています。
いいえ、データ ウェアハウスでは、ファクト テーブルに主キーまたは外部キーの制約を課すべきではありません。
いくつかの問題について言及しましたが、もう 1 つの問題は、これらの制約によって、行を挿入するときにパフォーマンスのオーバーヘッドが発生し、ETL プロセスのコストが高くなることです。
トランザクション データベース設計の経験しかない人にとって、これは、彼らが学んだことや経験したことすべてに反することになるかもしれません。外部キー制約は、複数のプロセスが同時にデータを変更するデータベースにとって重要です。開発者の最善の努力にもかかわらず、2 つのプロセスが何らかの形でデータを台無しにするという明確なリスクがあります。制約は、根本的に重要なセーフティ ネットです。
次元モデルでは、データベースは 1 つの ETL プロセスによってのみ、高度に制御された方法で取り込まれます。これにより、データが破損するリスクが大幅に減少し、制約の追加コストがそれだけの価値がないという点にまで達します。
于 2009-05-08T04:20:45.340 に答える
1
DWの更新は「ほとんど」制御されますが、常にではないため、FK制約が必要だと思います。たとえば、データの問題などが発生した場合は、手動でデータを修正します。[理想的にはこれは起こらないはずですが....:)]
キーがパフォーマンスに影響を与えないようにするために、ロードする前にキーを無効にして、再度有効にすることができます。これにより、データが正しいという確信が得られ、ロード中のパフォーマンスの問題も取り除かれる可能性があります。もう1つ覚えておくべきことは、処理時間はほとんどのデータウェアハウスにとって大きな制約ではないということです。
潜在的なデータ整合性の問題を修正するために必要な時間を考慮する場合、FKを持つことは十分に価値があります。
于 2011-05-06T13:26:46.767 に答える