Data integrity

Data such as addresses, contacts, and business partners have primary keys that are generated based on number groups and generated sequence numbers. Other data, such as departments, have a reference to this type of data, that is, a department has an address.

Before you export or import these types of data, you must take some precautions to avoid the risk of serious data corruption.

The following example illustrates how data corruption can occur when importing and exporting addresses and departments, and shows which precautions you must take to preserve data integrity:

Example

Addresses are imported and exported among these environments in the cloud:

  • TRN (Training)
  • TST (Testing)
  • PRD (Production)

If you use the same number-group series to create addresses in all three environments, the generated address codes can overlap between these environments.

Consequently, the same address code can point to different geographical locations in these environments. After the export or import is completed, severe data corruption can occur in the destination company.

Data corruption can even occur if the import is performed without overwriting the data in the destination company.

This may apply if you import master data such as departments, that have a reference to the addresses table.

If the address code of a department is the same in the source and destination environments but points to different geographical locations, the imported department is linked to an incorrect geographical location in the destination company after the import.

To avoid the overlap of generated keys between the environments and the resulting risk of data corruption, take either of these measures:

  • Define a unique system of record (SOR): maintain master data only in TRN, TST, or PRD and export the data to the other environments as needed.
  • Use different number group series for TRN, TST, and PRD. In this way, you can freely import addresses from TRN to TST, from PRD to TRN, and so on, and vice versa.