{% hint style="warning" %}
#### リレーションシップの保持
移行中に親レコードと子レコード間のリンクを保持するには、移行された子レコードには **リレーションシップ項目** 親レコードにそれらを接続するものです。これは、マスター詳細リレーションと参照関係の両方に適用されます。詳細については、次の記事を参照してください。
* [オブジェクトの関連を維持する](/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/obujekutonowosuru.md)
{% endhint %}
## データマスキング
データマスキングを使用すると、移行中に機密フィールドの値をターゲット組織に書き込む前にランダム化されたデータに置き換えることで保護できます。これにより、実際の顧客情報を公開することなく、サンドボックス環境やテスト環境で検証のための現実的なデータ構造を維持でき、チームがデータプライバシー要件への準拠を維持するのに役立ちます。データマスキングの詳細と、特定のフィールドに適用する方法については、次の記事を参照してください。
* [フィールドへのデータマスキングの適用](/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/frudohenodtamasukinguno.md)
## オブジェクト移行設定
各オブジェクトには、その移行方法を制御する個別の設定があります。これらの設定を使用して、レコード制限やレコードマッピングなど、オブジェクトレベルで移行動作を微調整します。
テンプレートのルートオブジェクトについては、移行中に転送されるルートレコード数の上限を設定できます。この上限はルートレコードにのみ適用され、子オブジェクトは独自のレコードを移行するため、移行されるレコード総数は設定した上限を大幅に上回る場合があります。次の記事では、この設定の仕組みと有効にする方法を説明しています。
* [移行レコード上限の設定](/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/rekdono.md)
Data Migrator は、複数回の移行実行にわたってレコードの正確性を維持するためにレコードマッピングを使用します。オブジェクトに対してレコードマッピングを有効にすると、Data Migrator はソース組織とターゲット組織の間で個々のレコードをマッピングし、後続の移行で新しいレコードのみが追加され、既存のレコードが更新されるようにします。次の記事では、レコードマッピングの仕組み、利用可能なレコードマッピングオプション、有効にする手順について説明します。
* [レコードマッピングの仕組み](/data-migrator/data-migrator-ja/tenpurto/yi-xing/rekdomappingunomi.md)
* [オブジェクトレコードマッピングの設定](/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/obujekutorekdomappinguno.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/data-migrator/data-migrator-ja/tenpurto/tenpurtodezain/tenpurtono.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
この **主従** アイコンは、子オブジェクトが親オブジェクトに密接に結び付いており、完全に依存している主従関係を示します。この関係では、親レコードが子レコードの特定の動作を制御します。主レコードが削除されると、関連するすべての従レコードも自動的に削除されます。データ移行中は、データの整合性を維持するために、親レコードを子レコードより前、または同時に移行する必要があります。
たとえば、Customer Meetings オブジェクトが Account オブジェクトと主従関係にある場合は、Account レコードと Customer Meetings レコードの両方を一緒に移行する必要があります。これにより、ソース組織から Account レコードが削除された場合でも、Customer Meetings レコードが削除されないようにできます。
[Salesforce - オブジェクト関係の概要](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### 参照関係 
この **参照** アイコンは、子オブジェクトが親オブジェクトを参照するが依存はしていない参照関係を示します。主従関係とは異なり、参照関係はより疎結合です。子レコードは親レコードを参照することも、親参照なしで独立して存在することもできます。親レコードが削除されても、関連する子レコードは自動的には削除されません。
たとえば、Case オブジェクトが Account オブジェクトと参照関係にある場合、Case レコードは関連する Account レコードがあってもなくても存在できます。関連する Account レコードが削除されても、Case レコードは保持され、削除されません。
[Salesforce - オブジェクト関係の概要](https://help.salesforce.com/s/articleView?id=platform.overview_of_custom_object_relationships.htm)
### 関係フィールド
この **関係フィールド** は、子レコードが親レコードを参照するために使用するフィールドです。各子オブジェクトの下に表示され、対応する親オブジェクトに接続する線が引かれています。以下のスクリーンショットでは、 **Customer Meetings** オブジェクトには 2 つの関係フィールドがあります。
* **CreatedById**： **Customer Meetings** オブジェクトを **User** オブジェクトに参照関係で接続します。
* **Account\_\_c**： **Customer Meetings** オブジェクトを **Account** オブジェクトに主従関係で接続します。
