ターゲットテーブルへの変更の取得

このテーブルには、変更前のデータが表示されます。

次の表に、販売担当者の名前が変更されたときのデータを示します。

変更を追跡する必要があるものの、すべての履歴値を格納しない場合は、更新可能なカラムごとに 2 つのフィールド (新しい値を記録するフィールドと変更の日付を記録するフィールド) を追加する必要があります。

• 新旧や最初と最後など、属性ごとに 1 つの変更のみを保持することができます。
• 各変更には、属性ごとに少なくとも 1 つの追加項目が必要であり、変更日付を記録する場合はもう 1 つの追加項目が必要です。
• テーブルの構造には必要なデータがすべて含まれていますが、特定の情報を抽出するために必要な SQL コードは複雑になる可能性があります。

制限付き履歴保存ではデータに変更を保存できますが、複数の変更に対応したり、サマリレポートのニーズを適切に処理したりすることはできません。

以下の例は、営業チームの値を保持する、制限された履歴の実装を示しています。

このテーブルには、変更前のターゲットテーブルのデータが表示されます。

この表は、営業員の営業チームが変更されたことを示しています。

無制限履歴保持により、データ変更管理に関連するほとんどの問題が解決されます。

• 重要な変更に対して新しい行を生成します。
• 一意のキーを使用する必要があります。
• オプションで、Effective_Date 項目、または 2 つの Valid_From 項目と Valid_To 項目を追加します。
• 任意で [IsActive] フィールドを追加します。

  その後、IsActive = Y でフィルタリングして、現在の行と期限切れの行を表示できます。

履歴を保持するには、単一のエンティティ (得意先や従業員など) に対して複数のレコードがテーブルにある場合に発生するターゲットテーブルの制約問題を管理する必要があります。

たとえば、販売レコードでは、営業員 ID が一次キーであり、そのレコードを営業員のすべての受注にリンクするために使用されます。同じ一次キーで新規レコードを追加しようとすると、例外が発生します。一方、新しい営業員 ID をその代表者の新しいレコードに割り当てると、営業員の総売上を正確にレポートする能力が損なわれます。

この問題に対処するには、サロゲートキーをターゲットテーブルの新しい列として作成します。サロゲートキーは、レコードの新しいプライマリキーになります。同時に、以前の一次キーのプロパティを単にデータ列になるように変更します。

同じ代理人の新規レコードが挿入されると、一意の代理キーが割り当てられます。これにより、営業員 ID を引き続き使用して、営業員の受注へのリンクを維持することができます。

このテーブルには、変更前のデータが表示されます。

無制限の履歴を保持を実装すると、この表に示されているように 2 つのレコードが表示されます。

Map_Operation トランスフォームでは、データセットの操作コードを変更して、必要な出力を生成することができます。たとえば、入力データセット内の行がデータフローの以前の操作で更新された場合、このトランスフォームを使用して UPDATE 操作を INSERT にマップします。その結果、ターゲット内の既存の行を保持するために、UPDATE 行を INSERT 行に変換できます。

Map Operation トランスフォームの入力は、任意のオペレーションコードでフラグが付けられた行を含むデータセットです。

Map Operation トランスフォームでは、入力データセットに必要な新しい操作を示すために、出力行タイプオプションの設定が有効になります。オペレーションコード INSERT、UPDATE、DELETE、NORMAL、または DISCARD から選択します。

例:

オプションで、行タイプごとに列ごとにマッピング式を記述することができます。