システム生成の主キーがあるデータ
システム生成キーがあるレコードについては、同じキーがあるレコードがターゲット環境にすでに存在するが、同じレコードを表していない場合、問題が発生します。ツールで、そのターゲット・レコードをソースの観点でのみ更新することで、ターゲットに存在する外部キー関係が壊れることがないようにする必要があります。
ツールでは、システム生成の主キーがある管理データをサポートしています。ロジックでは、レコードの他の属性("論理キー"とみなされる)を確認する方法を使用して、移行されるレコードがターゲット領域にすでに存在するかどうかを検出するために、メンテナンス・オブジェクトに依存します。この項の例は、「添付」メンテナンス・オブジェクトに基づいています。共通添付は管理データとみなされます。添付メンテナンス・オブジェクトでは、ファイル名と作成日を"論理キー"として使用します。
「標準料金コード」ファイルの共通添付が、キー123456789を使用するソース領域に存在するとします。次の表に、ターゲット領域で可能な状況、およびコンテンツ移行アシスタントでサポートされている処理を示します。
シナリオ | ターゲットの状況 | 処理 | コメント |
---|---|---|---|
1 | 一致レコードなし | レコードはキー123456789を使用して追加できます。 | |
2 | レコードはキー123456789で存在し、ロジックではこれが「標準料金コード」添付であることも確認します。 | レコードは更新できます。 | |
3 | レコードはキー123456789で存在しますが、ロジックではこれが「標準料金コード」添付でないことを確認します。 | レコードは更新されません。エラーが発行されます。 | このレコードは正しい添付レコードでないため、更新できません。 |
4 | 別のIDを使用する「標準料金コード」添付に対して、別の添付レコードが存在することが検出されます。 | レコードは更新されません。エラーが発行されます。 | レコードがターゲットで直接作成されたか、または別のソースからコピーされたことが前提です。 |
前述のシナリオ3と4で説明したユース・ケースでは、ソースからターゲットまでIDを追跡するためにキー・マッピングが必要であるため、このキーを外部キーとして参照するソースからの他のレコードは移行時に更新されます。この機能はサポートされていません。
前述のシナリオ1と2は、論理キーを検出する方法を使用するメンテナンス・オブジェクトの場合にサポートされています。
実装では、システム生成キーがあるレコードを同じ領域内に常に作成したり、標準移行パスに常に従ってデータをこのソース領域から他の領域に移動するなど、移行計画を確立することをお薦めします。この計画に従うと、前述のシナリオ4で説明したように、同じ論理キーのレコードを複数の場所に作成して異なるIDが生成される可能性を最小限または削減できます。
管理データと非管理データが混在するメンテナンス・オブジェクト
マスター・データやトランザクション・データおよび管理データが混在して含まれるメンテナンス・オブジェクトがあります。添付はこの一例です。製品では、共通添付および所有添付をサポートしています。所有添付は、その所有者に固有のレコードです。所有者はマスター・データまたはトランザクション・データが可能であるため、その添付はマスター・データまたはトランザクション・データとみなされます。所有添付は、コンテンツ移行アシスタントを使用する移行の対象ではありません。これに対して、共通添付は管理データとみなされ、コンテンツ移行アシスタントを使用する移行の対象になることが可能です。これらのユース・ケースの場合、実装では1つの領域のみに管理データを作成する推奨計画に従うことができるため、共通添付のIDは再利用されません。ただし、所有添付はターゲット領域に作成し、ソース領域から共通添付のキーに一致するシステム生成キーを受信できることが適切です。
この問題を最小限にするために、システムには、マスター・データやトランザクション・データとともに管理データが混在するメンテナンス・オブジェクトで使用される特別なロジックが含まれます。この特別なロジックによって、キーの中にゼロ(0)を使用する管理レコードのキーが生成されるため、この時点でマスター・データやトランザクション・データのキーにゼロは含まれません。この方法を使用するフレームワークのメンテナンス・オブジェクトの場合は、「フレームワーク提供の移行構成」を参照してください。使用しているエッジ・アプリケーションの場合、このカテゴリに属することが可能な追加のメンテナンス・オブジェクトの詳細は、コンテンツ移行アシスタントの付録を参照してください。