Persistence of the "golden record"

Choose a single view of the virtual MDM person or organization entities that you want to persist in the physical MDM domain. In most cases, this single view is the result of fixing overlapping and sometimes inconsistent information. The process is called survivorship.

The process of survivorship in your hybrid MDM solution involves establishing a well-defined set of criteria. The criteria determine which information to carry forward to compose a physical, single master view of the party. How you choose the criteria depends on your business needs. For example, you might choose to employ data recency as a criterion for carrying forward the more recent copy of the attribute. You might also choose to propagate (or, in other words, "survive") information from a source system. For example, the source system might store information that is collected from a call center rather than a source system that collects information from a public website.

InfoSphere® MDM Advanced Edition provides a default composite view for hybrid MDM that can be configured in the InfoSphere MDM Workbench for your hybrid MDM project. The default composite view corrects overlapping information by giving precedence to attribute data that is more recent. That is, the most recent attribute that contributes to the view is favored and persisted in physical MDM. By configuring business keys, you can determine which attributes overlap. Business keys are fields that together define the uniqueness for each attribute and they are configured in physical MDM. For more information about business keys, see the links at the end of this topic.

Only one composite view can be defined and used when the single view is persisted to physical MDM (using the persistEntity transaction). You can create your own implementation of a composite view. However, at a minimum, you must comply with the set of business keys that you define in physical MDM. If you change the composite view, you must use the batch processor to update any existing golden records in physical MDM. (The updating process resembles the Evergreening process of a pure physical MDM solution.)

After you define the view, you can use the persistEntity transaction to help create and maintain that view in physical MDM. As part of an initial or delta load, you can use the batch processor to invoke the transaction. The persistEntity transaction propagates virtual MDM entities to their centralized, “single golden master” representation in physical MDM. Virtual MDM can also trigger the persistEntity service when entities change. As changes are made to source system records that result in changes to the single composite view for an entity, an event notification system invokes the persistEntity service to update the physical MDM. Specifically, the persistEntity service creates, updates, or deletes the “golden master” representation of a person or organization entity in physical MDM. When the service is invoked, if an entity did not exist in physical MDM it is added. If it exists in physical MDM, it is updated. If it no longer exists in virtual MDM, it is deleted within physical MDM. (Note that a configuration parameter, deletionMode, allows you to specify whether the history for the entity is preserved when the entity is deleted (default behavior) or whether the history is deleted along with the entity.) The same processing logic applies to all attributes affiliated with the person or organization entity. Examples of such attributes include person name, party address, and so on.

In addition, persistEntity can create a representation in which only the cross-reference keys of an entity are stored. This cross-reference-only representation consists only of the virtual MDM entity ID and the unique identifiers for each source member record that is part of the entity. These representations are stored as contact equivalencies in physical MDM. When an entity is registered with only the equivalency keys in physical MDM, you can use the inquiry APIs for some of the person and organization services regardless of whether the composite view is persisted in physical MDM or retrieved as needed from virtual MDM.