SSISディメンションを使用する推論メンバーの問題SCDコンポーネント

Question

私はSSISディメンションマージSCDコンポーネント（http://dimensionmergescd.codeplex.com/）を使用しており、SCD1とSCD 2の両方で構成されている状況があります列。 InferredMemberフラグが設定されている行がありますが、コンポーネントは新しい行を挿入し、既存の推定行の現在のフラグをリセットしませんでした。

他の誰もこのコンポーネントを使用していて、正しく動作していることを確認しましたか？私は誤解していますか？私の理解はSCD2の列がSCD1になり、InferredMemberが真である、これは間違っていますか？

ソートはビジネスキーのデータベースで行われ、ソート列は一致するように設定されています。 DMSCDコンポーネントの出力は、OLE DB Command/OLE DB Destinationコンポーネントに直接フックされます。これは生産段階にあり、毎月正しく機能しています。あなたが唯一の推論されたメンバーとの問題を持っている

ExistingDimensionInputRowCount = 719941 
SpecialMemberInputRowCount = 1 
SourceSystemInputRowCount = 720516 
UnchangedOutputRowCount = 719941 
NewOutputRowCount = 720517 
DeletedOutputRowCount = 0 
SCD2ExpiredOutputRowCount = 0 
SCD2NewOutputRowCount = 0 
SCD1UpdatedOutputRowCount = 0 
InvalidInputOutputRowCount = 0 

Answer 1

私自身の質問に答えるために、間違っています。 InferredMemberフラグだけでは、推論メンバーの動作がトリガーされません。

推論されたメンバーは、ディメンションテーブルに挿入された骨格レコードです。多くの場合、ストアドプロシージャによって格納されます。 - ファクトテーブルのメンテナンス中にサロゲートキーのルックアップに失敗した場合InferredMemberフラグは、通常、ディメンション読み込みプロセスをトリガして、骨格推測メンバーレコードの残りのフィールドに入力します。推論メンバーレコードのSCD2フィールドの場合は、SCD1として処理され、新しいレコードは生成されません。

私は、推測されたメンバースケルトンに少なくとも過去のビジネスキー、推測メンバーフラグ、アクティブ日付を含める必要があることをDMSCDコンポーネントが判断できると判断しました。レコードは推測メンバーレコードとして扱われず、新しいレコードとして扱われ、重複が生成されていました。

DMSCDと互換性のある推定メンバーレコードの仕様を呼び出すドキュメントを見つけることはできませんでした。そのため、推定メンバーレコードは、作成されたストアドプロシージャによって適切に形成されます。私はまた、現在の日付であるアクティブな日付で推論されたメンバーレコードにタグを付けることができないことに疑問を呈します。

Answer 2

：

これは、実行の監査出力はありますか？ CodePlexでリリースされたコンポーネントの最新バージョンを使用していますか？

SCD2ハウスキーピング列（現在のメンバーと日付列）が正しく設定されていないため、推論されたメンバーだけに関連する問題ではありません。あなたはDMSCD後派生列コンポーネントを使用して日付を変更している、および/または/更新されていない

1. ：あなたはDMSCDから期待するとして、最も一般的な理由の出力は、次のいずれかに起因して配信されません。 DMSCDが提供する日付情報を挿入します。その代わりに、派生列でハードコーディングされた値または可変の値を使用しています。デフォルトではテーブル定義が使用されています。

2. DMSCDへの入力のソート順が正しくありません。 OLE DB Sourceの出力にIsSortedプロパティをtrueに設定し、列のさまざまなSortKeyPositionプロパティを設定するだけで十分であると仮定している可能性があります。そうではありません。作成した高度な編集を削除するか、フローのSortコンポーネントを使用します（テスト目的で、後でOLE DBソースを修正できます）。