The purpose of the EBX® Match and Merge Add-on is to find duplicate records which leads to creation or definition of a Golden record—a record that is either a unique record to be used directly, or the best record to use among a set of former suspect records—its life-cycle is described in detail in the following sections.
A golden record is important for any system because it is considered to be the best value that a table can provide from a set of suspect values. Each suspect that has been merged into a pivot or a golden record is easily traceable by means of a link automatically supplied by the add-on from the merged record to the pivot or the golden record. This makes it simple to retrieve a list of all records that have been merged into a pivot or a golden record.
The golden record can subsequently undergo other matches. For example, when creating a new record in the table, if this record matches with a golden record, the golden record is moved to the suspect state (or pivot if the 'Golden is preserved for selection record' property is set to 'Yes'; refer to matching policy configuration). When this situation occurs, it is no longer possible to get all past golden records. This can be of concern when systems must use golden records for update processes. In such situations, a suspect record that used to be a golden record will not participate in such processes.
To fix this issue, the add-on provides a field named 'was golden' that automatically follows this life cycle:
When a golden record is created, 'was golden' is set to 'No'.
When a golden record changes to another state (suspect, deleted, etc.), the 'was golden' is set to 'Yes'.
When a record goes into the golden state then 'was golden' is set to 'No'.
To get a full list of all current and past golden records, this data can be queried with EBX® directly.
By default, the 'was golden' value cannot be changed manually by an end-user. Only data repository administrators can change its value. Nevertheless, there are no restrictions preventing a custom procedure from modifying the information under certain conditions. For example, once legacy systems have been aligned with past golden records, a realignment of the 'was golden' values can be performed.
When a record's 'was golden' property is 'Yes' and it is in the suspect or pivot state, the user can set its state back to golden, bypassing any matching or merging operations.
During enforcement of survivorship policies, a suspect with a 'was golden' state of 'Yes' can be merged automatically. The record then goes into the merged state with 'was golden' still equal to 'Yes'. In this situation, the add-on does not allow the 'set back golden' operation as a merge has occurred.
A 'Set definitive golden' service can be applied to any suspect, pivot, unmatched or golden record. The record moves to the reserved '003' cluster with its state set as golden. When a matching is executed at any level (table, cluster, real-time, batch) all records located in the '003' cluster are ignored.
Services that are available for golden records in the '003' cluster are the same as for other golden records in other clusters.