問題タブ [scd]

私のシナリオでは、ゆっくりと変化するディメンション タイプ 2 の使用方法を理解するのに苦労しています。さまざまなチュートリアル Web サイトを調べましたが、それらは適合しません。

以下を含む従業員ディメンション テーブルがあります。

Account Fact テーブルがあります

ディメンションが変更され、同じ Ola 従業員に新しい ID が付与されていることがわかります。ファクト テーブルでどのように管理しますか?

• Ola の新しい ID は Fact Table に見つかりません。

• したがって、Ola という新しい ID を使用して実際に新しい行を追加すると、「主キー」とは異なる方法で識別される場合に、同じ従業員であることをどのように関連付けることができるでしょうか。

• この従業員が新入社員ではなく、実際に場所/指定が変更されたことをどのように区別しますか。

説明の間違いを含む製品テーブルがあるとします。測定単位が「grams」ではなく「garms」とつづりが間違っていました。タイプ 1 - SCD 手法を表すクエリ ステートメントを使用して、これをどのように実装しますか。

複数のソース システムからのデータの統合を伴うデータ ウェアハウス プロジェクトに取り組んでいます。私は、顧客ディメンションを設定し、緩やかに変化するディメンション ツールを使用して顧客の更新を追跡する SSIS パッケージをセットアップしました。

いくつかの問題が発生しています。次の例を見てください。

ソース システム A には、次のようなレコードが含まれている可能性があります。

名、姓、郵便番号 Jane、Doe、14222

ソース システム B には、次のような同じクライアントのレコードがある場合があります。

名、姓、郵便番号 Jane、Doe、Unknown

最初にシステム A からレコードをインポートすると、名、姓、および民族が表示されます。偉大な。ここで、システム B からクライアント レコードをインポートすると、ファジー マッチングを実行して、これが同一人物であることを認識し、緩やかに変化するディメンション ツールを使用して情報を更新できます。ただし、この場合、「不明」が有効なデータを上書きするため、郵便番号が失われます。

この問題に間違った方法で取り組んでいるかどうか疑問に思っています。SCD ツールは、新しいデータが有効かどうかに基づいて属性を選択的に更新する方法を提供していないようです。マージステートメントの方がうまくいくでしょうか? 目に見えない基本的な設計上の間違いを犯していますか?

アドバイスをありがとう！

SCD type2 の例を実装しようとしています。だから、empid、ename、location、hiredate、startdate、enddate、およびフラグを使用してテーブルを作成しています。当初、hiredate と startdate は 01-jan-2012 で、enddate はデフォルトで 01-jan-2099 であると仮定します。終了日が 2099 年 1 月 1 日である場合、フラグは「Y」のままで、現在のアクティブな情報が表示されます。

誰かが場所を更新するたびに、その従業員の新しい行が追加され、new.startdate が同じ従業員の前の行 (古い行) の更新された古い終了日になり、new.enddate はデフォルトで 01-jan- になります。 2099、およびフラグを「Y」に設定します。

従業員の古い行は履歴データを表し、終了日を systemdate に設定し、フラグを "N" に設定します。トリガーのアクションを実行する順序を理解できず、行き詰まっています。