Understanding data change detection

This topic details the process and architecture for the data change detection mechanism.

The InfoSphere® MDM mechanism for data change detection is as follows:

  1. Upon completion of an add, update, or delete transaction, a generic critical data change dispatcher checks all of the associated response business objects.
  2. Beginning with the topmost object in the hierarchy of response business objects, the dispatcher checks to see if there are any handlers defined for this object. A handler is an implementation of the IDCObjectHandler interface. The dispatcher's job is to assign handlers to check for changes to a business object.
    Note: For details about handlers, and for information about creating a custom handler, see Creating a custom business object handler.
  3. If a handler is specified for a given business object, the dispatcher passes the business object to the handler.
  4. Each handler uses whatever algorithm it requires to determine if there are any changes to the business object that would necessitate suspect reidentification. If such changes exist, the affected business object is added to a list of business objects requiring suspect reidentification.
  5. When the handler is done with a given business object, it returns control to the dispatcher. The dispatcher then moves on to the next business object in the hierarchy of response business objects and repeats the process.
  6. After the dispatcher has checked all of the objects in the response business object hierarchy, then it builds a complete list of the business objects requiring suspect reidentification.
Note: Historical changes within active records are not kept in the InfoSphere MDM Probabilistic Matching Engine tables. Instead, the old values are overridden or updated in the InfoSphere MDM Probabilistic Matching Engine search index.

The overall architecture of the data change detection process is illustrated in the following figure.

Data change detection architecture

In the data change detection example shown in the following figure, a ContractBObj business object has been updated in an updateContract transaction.

The process flow of a sample update to a Contract entity that triggers suspect reidentification tasks for a related Person and Organization
Note: The numbers in the preceding figure represent the order that the IObjectHierarchyMetadata interface will process the business objects in this situation.

In this case, updating a single Contract entity results in associated updates to both a Person entity and an Organization entity. Such an update requires suspect reidentification to be carried out twice: once for the Person entity and once for the Organization entity.