5つのディメンションテーブルが関連付けられたファクトテーブルがあります。通常、ファクトテーブルには各ディメンションのサロゲートキーが含まれており、ビジネス/サロゲートキーはありません。ステージングファクトテーブルの結果、つまり新しいレコードを挿入したファクトテーブルをロードしようとしています。しかし、事実テーブルは、データの更新や削除などの他の操作も処理できることがわかりました。この目的のためにSSISパッケージで条件付き分割が使用され、代理キーがすべて0であるかどうかを確認して新しい挿入を行いました。私の質問は、更新または削除の観点から代理キーを使用できますか？ファクトテーブルのレコードの更新と削除
私は、データがどのように見えるかを知るためにファクトテーブルに挿入しました。
答えはイエス、あなたができることです。しかし、1人の従業員が同じサプライヤーから同じ顧客に同じ製品を同日に販売したという状況がありますか？おそらく同じ日に異なる注文ですか？
サロゲートキーがすべて一意にレコードを識別できる場合は、ファクトレコードをハートコンテンツに更新します。しかし、そうでない場合は、更新を予定していないときにレコードを更新する可能性があります。
このような事態を避けるために私が設計したファクトテーブルに注文番号を含める傾向がありますが、実際のファクトテーブルにその番号が含まれていないことがあります。注文番号を含めると、ファクトテーブル内のdegenerate dimensionというパターンが使用されます。私はそれがかなり便利だと分かった。
とにかく、答えは同じです。サロゲート・キーに基づいてファクト・レコードを更新するには、それらのすべてが一緒に更新する行を一意に識別できる限りです。
風に注意を払わないでください。必要に応じてデータウェアハウスが設計されていることを確認してください。ファクトの更新を行うことができれば、ETLプロセスのステップ数が少なくて済む点で、削除と置き換えの方が効果的です。
有益なお返事ありがとうございます。はい、ETLプロセスに各ディメンションの更新などを処理させます。これは、OLDBコマンドによる新規エントリまたは更新の場合にディメンションをステージングすることによって作成されました。その後、各ディメンションからファクトテーブルをステージングし、ゆっくりと変化するベースとして各ディメンションを読み込み、レコードが変更されると更新されるようにしました。 – Dodi
あなたが思ったような音、素敵です。がんばろう！！ –
私はデータウェアハウスを構築しましたが、デプロイメントの問題があります。私はこのサイトを通してエラータイプの質問をして助けを求めようとしましたが、これまでに何があったのか運がありません：_（ – Dodi
ファクトテーブルにプライマリキーがない場合、更新または削除するレコードを特定することは運が必要です。 –
ファクト表の主キーは必要ではなく、有用な目的を果たさない可能性があります。 – Dodi