The purpose of this information is to highlight the steps that AddressBase, AddressBase Plus and AddressBase Premium users should take into consideration when applying change-only update (COU) to their product data holdings or when creating a COU process to align with their existing business processes. This page aims to give a synoptic view of the COU process and recommends steps that should be followed by you to ensure a standard in the way COU is applied.
A change only update (COU) supply of data contains records or files that have changed between product refreshes to a customer.
COU data enables a user to identify three types of change:
1) Inserts (CHANGE_TYPE ‘I’) are objects that have been newly inserted into your area of interest since the last product refresh.
2) Deletes (CHANGE_TYPE ‘D’) are objects that have ceased to exist in your area of interest since the last product refresh.
3) Updates (CHANGE_TYPE ‘U’) are objects that have been updated in your area of interest since the last product refresh.
Step 1: Load the baseline supply
The most important thing to do is to load the ‘baseline’ supply of the product that you are evaluating. This should be done as per your usual loading procedure. This will give you a base on which to apply the COU supply.
Step 2: Apply the COU supply to the baseline using the appropriate product or format rule:-
AddressBase Premium COU Rules
The following rules will apply to COU in CSV format:
- All files shall contain Header records and Trailer records as the first and last Records in the file.
- Files must be processed in date and time order.
- For multiple files that cover the same data range, the files shall be processed in order according to the volume number in the HEADER Record and in the file name.
- The FILE_TYPE field shall be set to “C” in the header record.
The following rules will apply to COU in GML format:
All data within the COU file shall be treated as the changeType indicated within the FeatureWithLifecycle class.
AddressBase and AddressBase Plus COU rules
The following rules are applicable to users of both CSV and GML AddressBase and AddressBase Plus:
Read through all the COU files and apply in the following order based upon the change type:
Each feature can be used to overwrite the existing record.
Step 3: Handling COU load errors
In the first instance if the loading of a file results in any of the following scenarios the file should not be loaded into the database and the user should be alerted:
- The file attempts to insert a record on a unique identifier that already exists in the database.
- The file attempts to update a record that does not already exist in the database.
- The file attempts to delete a record that does not exist in the database.
These may indicate that the file is corrupt or the local database is not synchronised with the national set.
In order to correct issues and ensure synchronicity it is recommended that the following functionality is available should there be a need to override the rules above.
- Update records (record identifier ‘U’) should be treated as an Insert record (‘I’) if the unique ID does not exist in the database.
- Insert records (‘I’) should be treated as an Update record (‘U’) if the unique ID already exists in the database.
Allow the re-insertion of a previously deleted record from the current COU files.
Step 4: Archiving
When users are Deleting, Inserting or Updating features it is up to the individual users to consider their archiving requirements. For example, if deleted records are important to your organisation you must take the appropriate action to archive previous records.