0

EDW テーブル (履歴レコードを維持する) からディメンションをロードする必要があり、タイプは Key-Value-Parameter です。

以下のように EDW でレコードを取得した場合、私のシナリオは問題ありません

Key1  Key2   Code     Value     EffectiveDate           EndDate        CurrentFlag
100   555     01      AAA       2010-01-01 11.00.00     9999-12-31         Y
100   555     02      BBB       2010-01-01 11.00.00     9999-12-31         Y

これは、次のようにピボットして DM にロードする必要があります。

key1 と key2 の組み合わせにより、DM の自然キーが作成されます

 SK    NK       01     02        EffectiveDate        EndDate      CurrentFlag
 1    100-555   AAA    BBB       2010-01-01 11.00.00  9999-12-31        Y

私のssisパッケージは、これをすべて適切にピボットします... DIMで受信NKを検索します..新しい場合は挿入されます..それ以外の場合は、発効日をさらに検索して、同じ自然キーの受信が属性に新しい（変更）があるかどうかを判断します.. その場合、終了日を設定して現在のレコードを更新し、新しい属性値で新しいレコードを挿入し、他の属性の最近のレコード値を取得します。

私の問題は、単一の抽出で同じ属性を持つ同じ自然キーが2回来る場合、最初のルックアップで、自然キーで..両方のレコードを通過させ、挿入しようとします..失敗する場所です。NKで個別のレコードを取得した場合、2番目は選択されず、パッケージを再度実行する必要があります。

したがって、同じNKが単一の抽出で2回来る場合、このシナリオを処理するためのルックアップまたは代替方法をどのように構成できますか? Dimテーブルに存在しない場合は最初のレコードを挿入でき、2番目のレコードは上に挿入されたものへの参照。

これが何を説明しようとしているのかわからない。スクリーンショットを添付して、作業デスクに戻します (月曜日)。

ありがとう

4

2 に答える 2

0

Cade のコメントは的を射ていますが、あなたの主な問題は重複だと思います。「ソース」ストリームに同じ NK の 2 つのバージョンがあるという事実は、2 つの別個の意味のあるバージョンを示していますか? それとも、「最後の」バージョンだけが重要ですか?

両方のバージョンに反映された変更をディメンション テーブルに反映する必要がある場合は、処理をバッチに分割するという Cade の提案に同意します。入力を NK (および変更時間) で並べ替え、行カウント スクリプトを使用して各 NK の「バージョン」を列挙し、バージョン番号で「バッチ」を処理できます。

最後の「バージョン」のみをディメンション テーブルに組み込む必要がある場合は、ルックアップを使用する前に重複を排除することをお勧めします。

于 2010-06-07T23:52:14.347 に答える
0

ルックアップはこれには適していません-キャッシュとすべてを使用すると、以前に設定された値をルックアップできません。

それを SQL コマンド タスクに渡し、ストアド プロシージャが検出内容に応じて挿入または有効期限/挿入を実行する方がよい場合があります。

それらをテーブルにストリーミングして、バッチで実行することもできます。

フローとそれが入力しようとしているモデルに対処するには:

まず、入力の行の順序が動作の違いを引き起こす場合、常に厄介です。つまり、NK = A、Val = 1 の場合、NK = A、Val = 2 は、NK = A、Val = 2、NK = A とは異なる動作を示します。 、Val = 1.これが正しい次元設計であるかどうか疑問に思う必要があります。すべてのディメンション属性は、実用的な選択に基づいてディメンション テーブルに割り当てられることに注意してください。最終的には、ディメンションを自由にテーブルに配置できるため、別のデザインの方が理にかなっている可能性があります。1 回の読み込みで状況が変化している場合は、その負荷を分割して粒度を合わせる必要があることを示している可能性があります (一度に 2 日間のデータを読み込もうとしないでください)。

ディメンションに発効日と終了日があることに気付きました。現時点では、これはディメンションの動作 (NK で 01 と 02 のコードが変化する) のプロパティのように聞こえますが、このディメンションが関連付けられるという事実のプロパティではありません。これは、(SK、EffectiveDate、EndDate) などの別のファクトレス ファクト テーブルで追跡する必要があることを示している可能性があります。または、ファクトに関連付けられた NK、01、02 の組み合わせだけが重要であるため、重要ではないことを示している可能性があります。この場合、自然キーは実際には NK、01、02 のすべてです。

ファクト テーブル、受信フィード、および予想される使用状況に戻り、さらに詳しく調べて、これらのディメンションの変化を追跡する別のファクトレス ファクト テーブルが必要かどうかを確認することをお勧めします。

また、詳細を投稿していただけると助かります。ビジネス ケースをもっと見ると、Kimball の資料がそれについて何と言っているかがわかります。

于 2010-06-05T17:19:10.550 に答える