内部代理キーとタイプ 2 の緩やかに変化するディメンションを使用するデータ ウェアハウスがあります。クリアリングでは、次のように、erp システムからのビジネス キーのみを取得します。
データ ウェアハウスでは、代わりに代理キーを使用したいと考えています (注: 記事の価格が 500 ドルから 1000 ドルに変更され、可能であれば記事は代理キーを使用しています。ここでは製造元のみ)。
ビジネス キーのみを使用していた場合は問題ありません。古いエントリを比較して更新し、新しいエントリを挿入するだけです。しかし、代理キーでこれを行う最良の方法は何ですか?
クリアリングでデータ ウェアハウスから既存の ID (まだ存在しない場合は 0 または -1) を取得し、エントリを比較しますか?
ビジネス キーをデータ ウェアハウスにも保持し、それらを比較して ID を更新してから、データ ウェアハウスに入れますか?
テーブルをロードするときにルックアップを実行できるようにするには、記事をロードするときにメーカーを参照する場合と同様に、自然/ビジネス キーを DWH に格納する必要があります。私の経験から、これは常に行われます。
ただし、ソース エンティティのビジネス キーは、宛先エンティティにのみ格納する必要があります。はっきりさせておきますが、製造元のビジネス キーは、DWH の製造元テーブルにのみ表示され、他の場所には表示されません。Article など、別のテーブルで製造元を参照する必要がある場合は、製造元の代理キーを使用します。
つまり、2 番目のスクリーンショットで正しく理解できました。
次に、Article テーブルをロードし、特定の記事の製造元が変更されたかどうかを知る必要がある場合は、まず、ビジネス キーに基づいて製造元の代理キーを検索し、その代理キーを Article テーブルのキーと比較します。これが通常行われる方法です。