レコードマッピングの仕組み

概要

Data Migrator はレコード マッピングを使用して、複数回の移行実行にわたってレコードの正確性を維持します。オブジェクトでレコード マッピングを有効にすると、Data Migrator はソース組織とターゲット組織の間で個々のレコードを対応付けるため、その後の移行では新しいレコードのみが追加され、既存のレコードは更新されます。テンプレート内では、各オブジェクトごとにレコード マッピングを個別に制御します。Data Migrator では、ソース組織とターゲット組織の間でレコードをマッピングするために 2 つの方法を提供しています: 自動 と 手動。以下のセクションでは、各方法の仕組みを説明し、レコード マッピングの成功例と失敗例を示すサンプル シナリオを紹介します。

• レコードマッピングの仕組み

• レコードマッピングの仕組み

• レコードマッピングの仕組み

レコード マッピングの有効化

デフォルトでは、テンプレート内のすべてのオブジェクトでレコード マッピングは無効です。レコード マッピングを有効にしない場合、移行時にソースのすべてのレコードが常にターゲット組織に挿入されます。これは、同じレコードが両方の場所に存在する場合、重複を引き起こす可能性があります。

オブジェクトのレコード マッピングは、［設定］タブから有効にします。次の記事では、オブジェクトのレコード マッピングを有効にする方法を説明しています。

• オブジェクトレコードマッピングの設定

自動レコード マッピング

自動レコード マッピングは、ソース レコードとターゲット レコードを関連付けるために内部マッピング テーブルを使用する、状態を保持するマッピング ベースの戦略です。これは、リアルタイムのターゲット データではなく、過去のデプロイで作成された履歴マッピングに依存します。ソースからターゲットへのマッピングが一度存在すると、その関係は固定されるため、自動で移行済みのレコードに関してはあいまいさがありません。

自動は、次のような場合の繰り返し移行向けに設計されています:

• 使用している移行ツールが Data Migrator のみである
• 初回移行時にターゲット組織が空である
• 実行をまたいだ長期的な一貫性が必要である

自動は次のことを保証します:

• 同じソース レコードは常に同じマッピング済みターゲット レコードを更新する
• ビジネス フィールドの変更はレコード照合に影響しない
• マッピングが存在すれば、レコード更新は決定的である

ただし、自動はリアルタイムのターゲット データを評価しません。

自動の仕組み

自動は、決定論的なマッピング駆動プロセスに従います。下の図は全体の流れを示しています。

1

ソース レコードを読み取る

移行実行中、各ソース レコードは個別に処理されます。

2

データベースでマッピングを検索する

システムは、ソース レコードの ID に対するマッピングがすでに存在するかどうかを確認します。

3

マッピング結果を評価する

マッピングが見つかった	操作
いいえ	ターゲット組織に新しいレコードを挿入します。
はい	既存のマッピング済みターゲット レコードを更新します。

4

マッピングを保存する

マッピングが存在しない場合、システムはレコードをターゲット組織に挿入し、新しいマッピングを作成します。その後の移行では、このレコードは再度挿入されるのではなく更新されます。この処理は実行ごとに繰り返されるため、新しく追加されたソース レコードはデータベースで追跡されます。

制限事項

自動レコードマッピングの重要な制約

• 自動では、すでにターゲット組織に存在するレコードをマッピングできません。
• 別のツールまたは手動プロセスがターゲット組織内でレコードを作成または変更した場合、自動マッピングが古くなり、重複レコードが発生する可能性があります。
• 自動は、Data Migrator を通じて移行されたレコードのみを追跡できます。

古くなったマッピング

自動の信頼性は、そのデータベースの信頼性に依存します。ターゲット組織でレコードが手動または別のツールによって作成されると、マッピングは古くなります。以下の例では、これがどのように重複レコードにつながるかを示しています。

例:

1. ユーザーが、すべての Contact レコードを空の組織へ移行します。

   1. すべての Contact レコードがソースからターゲット組織へコピーされます。
   2. 各レコードに対して自動マッピングが作成されます。
2. ユーザーが次の Contact レコードを手動で作成します Charlie と Alice ソース組織とターゲット組織の両方で。
3. ユーザーが、ソース組織からターゲット組織へすべての Contact レコードの別の移行を実行します。

   1. Charlie と Alice 以前に移行されていないため、自動マッピングがありません。
   2. 次の新しいレコードが Charlie と Alice ターゲット組織で作成されます。
   3. ターゲット組織には次のレコードの重複が存在します Charlie と Alice: 1 つは手動作成によるもの、もう 1 つは移行によるものです。

手動レコード マッピング

手動レコード マッピングでは、1 つ以上のレコード フィールドを組み合わせて、ソース レコードとターゲット レコードを結び付ける複合 ID を作成します。標準の Salesforce 外部 ID とは異なり、複合 ID には任意のフィールドを使用できます。手動がターゲット組織を検索して一致するレコードをちょうど 1 件見つけると、新しいレコードを挿入する代わりにそのレコードを更新します。

これは、すでに自動レコード マッピングでマップされていないレコードを含むターゲット組織、または他のツールによって作成されたターゲット組織内のレコードへ移行するために設計されています。手動レコード マッピングのフィールドは慎重に選択してください。選択したフィールドのいずれかの値が変わると、マッピングは以前に移行したレコードと一致しなくなります。

手動の仕組み

手動レコード マッピングでレコードを移行する前に、対象オブジェクトでレコード マッピングに使用する 1 つ以上のフィールドを選択する必要があります。選択したフィールドは組み合わされ、固有かつ安定したキーを作成します。つまり、よく更新されるレコード フィールドが変更されてもキーは変わらず、組織内の各レコードに対して一意になります。手動キーには 1 つ以上のフィールドを選択できます。選択するフィールドが多いほど、キーが一意になる可能性は高くなります。ただし、フィールドを増やすと、キーが不安定になる可能性も高まります。

手動レコード マッピングでは、処理が生成されたキーと一致するものをターゲット組織で検索します。下の図と説明は、その仕組みを示しています。

1

ソース レコードを読み取る

移行実行中、各ソース レコードは個別に処理されます。

2

キーを生成する

A キー は、手動マッピング用に選択されたレコードのフィールドから生成されます。

3

ターゲット組織をクエリする

ターゲット組織で次の項目に対する SOQL クエリを実行します: キー.

4

クエリ結果を評価する

一致したレコード数	操作
0	ターゲット組織に新しいレコードを挿入します。
1	一致した既存のターゲット レコードを更新します。
2 件以上	エラー - レコードはスキップされます。複数のレコードが次と一致するため キー、このレコードの手動キーは一意ではなく、レコードを移行できません。

制限事項

手動レコードマッピングの重要な制約

各レコードに一意のIDを作成する、安定したフィールドの組み合わせを選択することが重要です。

• 安定：キーとして選択したフィールドのいずれかの値が変更されると、手動マッピングは以前に移行されたレコードと一致しなくなり、新しいレコードが挿入されて重複が発生します。
• 一意：ソース組織で2つ以上のレコードが同じキーを共有している場合、キーが一意ではないため、移行はそれらをターゲットレコードに正しくマッピングできません。

不適切な手動フィールド

手動レコード マッピングは、手動マッピングに選択したフィールドが、安定していて一意なキーを作成する場合にのみ信頼できます。以下は、適切でないフィールド選択の例です。

次の例では Contact オブジェクトを使用します。

キーに選択されたフィールド	これらのフィールドが不適切な理由
名前 と 市区町村	たとえ 名前 と組み合わせると、 市区町村 連絡先の市区町村は変更される可能性があるため、キーが不安定になります。
役職 と 部門	この組み合わせは一意ではありません。複数の連絡先が同じ役職と部門を共有できるためです。
名前 と 誕生日	この組み合わせは一意で安定しているように見えますが、 誕生日 最初は空欄で後から入力されることが多いため、キーが不安定になります。

レコード マッピングのシナリオ

テンプレート設計

オブジェクト: Contact

• フィールド: 名前
• フィールド: メール
• フィールド: 市区町村

下の表では、相違点を太字で示しながら、ソースとターゲットのレコードを示しています。

ソース組織の Contact レコード

ID	名前	メール	市区町村
001D000000kL4p1	Alice	[e-mail]	ベルリン
001D000000kL4p2	Bob	[e-mail]	ロンドン
001D000000kL4p3	Charlie	[e-mail]	パリ
001D000000kL4p4	Dave	[e-mail]	シアトル

ターゲット組織の Contact レコード

ID	名前	メール	市区町村
002D000000kL5p1	Alice	[e-mail]	ニューヨーク
002D000000kL5p2	Bob	[e-mail]	ロンドン
002D000000kL5p3	Charlie	[e-mail]	パリ

自動レコード マッピングを使用したデータ移行

成功シナリオ

このシナリオでは、以前の移行でソース組織とターゲット組織の間にすでに自動マッピングが作成されています。下の表はそのマッピングを示しています。

ソース名	ソース ID	ターゲット ID
Alice	001D000000kL4p1	002D000000kL5p1
Bob	001D000000kL4p2	002D000000kL5p2
Charlie	001D000000kL4p3	002D000000kL5p3

移行が実行されると、自動レコード マッピングは既存のマッピングから各ソース レコードの ID を検索します。保存済みのマッピングがあるレコードはターゲット組織で更新され、マッピングがないレコードは新規レコードとして挿入されます。下の図と表は、この処理とターゲット組織での結果の操作を示しています。

ID	名前	メール	市区町村	操作
002D000000kL5p1	Alice	[e-mail]	ベルリン	更新
002D000000kL5p2	Bob	[e-mail]	ロンドン	更新
002D000000kL5p3	Charlie	[e-mail]	パリ	更新
002D000000kL5p4	Dave	[e-mail]	シアトル	挿入

その後、新しく挿入されたレコードに対して新しい自動マッピングが追加されます:

ソース名	ソース ID	ターゲット ID
Dave	001D000000kL4p4	002D000000kL5p4

失敗シナリオ

このシナリオでは、以前の移行でソース組織とターゲット組織の間にすでに自動マッピングが作成されていました。ただし、その時点でマップされていたレコードは 2 件のみでした。下の表はそのマッピングを示しています。

ソース名	ソース ID	ターゲット ID
Alice	001D000000kL4p1	002D000000kL5p1
Bob	001D000000kL4p2	002D000000kL5p2

次の移行の前に、外部ツールが Charlie のレコードをソース組織とターゲット組織の両方に追加します。移行が実行されると、自動は既存のマッピングで各ソース レコードの ID を検索し、すでにマッピングがあるターゲット レコードを更新し、マッピングがないものには新しいレコードを挿入します。

下の図と表は、この処理とターゲット組織での結果の操作を示しています。Charlie の自動マッピングが存在しないため、移行では重複レコードが挿入され、追加で挿入された行に示されています。

ID	名前	メール	市区町村	操作
002D000000kL5p1	Alice	[e-mail]	ベルリン	更新
002D000000kL5p2	Bob	[e-mail]	ロンドン	更新
002D000000kL5p3	Charlie	[e-mail]	パリ
002D000000kL5p4	Charlie	[e-mail]	パリ	挿入
002D000000kL5p5	Dave	[e-mail]	シアトル	挿入

新しく挿入されたレコードに対して 2 つの新しい自動マッピングが追加されます:

ソース名	ソース ID	ターゲット ID
Charlie	001D000000kL4p3	002D000000kL5p4
Dave	001D000000kL4p4	002D000000kL5p5

移行は失敗しました。外部ツールが Charlie をソース組織とターゲット組織の両方に、自動マッピングを作成せずに追加したためです。Charlie のマッピングがないため、自動は既存のレコードを更新する代わりにターゲット組織に新しいレコードを挿入し、その結果、重複が発生しました。

手動レコード マッピングを使用したデータ移行

成功シナリオ

手動フィールド キー: 名前

このシナリオでは、手動レコード マッピングは構成済みのキーを使用してレコードを照合します。 名前 を手動キーとして、システムは各ソース レコードのキーを生成し、一致するものをターゲット組織に問い合わせます。ちょうど 1 件一致したレコードは更新され、一致しなかったレコードは挿入されます。下の図と表は、手動レコード マッピングの処理とターゲット組織での結果の操作を示しています。

ID	名前	メール	市区町村	操作
002D000000kL5p1	Alice	[e-mail]	ベルリン	更新
002D000000kL5p2	Bob	[e-mail]	ロンドン	更新
002D000000kL5p3	Charlie	[e-mail]	パリ	更新
002D000000kL5p4	Dave	[e-mail]	シアトル	挿入

失敗シナリオ

手動フィールド キー: 名前 + メール

このシナリオでは、手動レコード マッピングは 名前 + メール を構成済みのキーとして使用します。各ソース レコードについて、システムはこのキーを生成し、一致するものをターゲット組織に問い合わせます。Bob のソース レコードではキー フィールドの 1 つに新しい値があるため、ターゲット組織内の彼のレコードとは一致しなくなっています。

ちょうど 1 件一致したレコードは更新され、一致しなかったレコードは挿入されます。下の図と説明は、手動レコード マッピングの処理とターゲット組織での結果の操作を示しています。Bob のソース キーが既存のターゲット レコードと一致しなくなったため、移行では重複が挿入され、追加で挿入された行に示されています。

ID	名前	メール	市区町村	操作
002D000000kL5p1	Alice	[e-mail]	ベルリン	更新
002D000000kL5p2	Bob	[e-mail]	ロンドン
002D000000kL5p3	Charlie	[e-mail]	パリ	更新
002D000000kL5p4	Bob	[e-mail]	ロンドン	挿入
002D000000kL5p5	Dave	[e-mail]	シアトル	挿入

移行は失敗しました。Bob の メール 値が、ターゲット レコードが作成された後にソース組織で変更されたためです。 メール は手動キーの一部であるため、ソース レコードから生成された新しいキー (Bob + [e-mail]) は、既存のターゲット レコードのキー (Bob + [e-mail]) と一致しなくなりました。一致が見つからなかったため、手動は既存のレコードを更新する代わりにターゲット組織に新しいレコードを挿入し、その結果、重複が発生しました。