If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Matching Configuration

Matching is a crucial MDM process used to identify and handle duplicate records representing the same business object (for example, a customer) across different data sets coming from different primary systems, which is typical for Consolidation and Coexistence MDM implementation styles. It involves comparing new or existing data against stored records using rules to detect similarities and discrepancies.

The matching process can be used regardless of whether data is loaded from all systems at once, from a single system, or only includes changed records.

After duplicates are detected, each record in the group is assigned a unique identifier (master ID) and specific metadata (for example, a rule name). This identifier is then used in the merging process to combine all relevant information into a single, accurate golden record, also referred to as master record.

As part of the matching process, deduplication of related or child entities is performed. Deduplication ensures that related silver records (for example, address) remain unique within the context of their parent entities.

Matching primarily operates at the instance layer, working with individual records. However, the same logic can be applied to master data in Centralized or Mixed MDM styles, see Matching on master entities.

In MDM, matching can be performed in three ways: automatically, manually, or through matching proposals, which provide an intermediate option between the two (generated automatically and resolved manually).

Automated matching

Matching and merging are automatically performed in MDM based on predefined matching rules set in the matching configuration. In cases where automated matching encounters ambiguities or constraints, and in the case that some special proposal rules are defined in the matching configuration, matching proposals are generated that require manual resolution.

Manual matching

The effectiveness of automated matching depends on the accuracy of the rule configuration and the quality of the processed data. In situations where records are incomplete or automated matching does not produce the desired results, it is possible to browse, compare, and merge records manually. Alternatively, you can create manual matching tasks for team members. You can also perform split and rematch operations to refine matching outcomes.

During the manual matching process, the MDM engine offers a merge preview, which displays how the golden record will appear after the matching is performed. You can modify the result by selecting or entering new values (similar to the editing process).

Matching proposals, which are generated from automated matching, are also reviewed and resolved manually.

Matching proposals

Matching proposals represent a hybrid approach between automated and manual matching processes. They are generated as a result of automated matching and suggest potential duplicates but require manual resolution to confirm, reject, or adjust the suggested matches. This resolution process is identical to the manual matching workflow.

Additionally, it is possible to search for related matching proposals and resolve them in bulk.

Matching proposals are generated in the following cases:

There are specific proposal rules defined in the matching configuration.
There are some constraints applied that prevent the system from correctly assigning records to individual master records within a matching group.
A record on MDM input matches several existing groups but cannot be automatically merged to more than one record.
AI Matching was used.

Currently, it is not possible to generate matching proposals for already processed data when records are updated. You can reprocess the data with rematching enabled instead. However, your manual match decisions will not be preserved in this case.

Matching stability

Matching stability is a key principle in MDM that ensures matched records remain consistent over time. Once records are matched and consolidated into a golden record, this match remains stable, even if there are subsequent changes in individual data attributes.

By default, data changes do not trigger reevaluation of matching decisions. This means that the system will not automatically merge two groups or rematch data that already has a master ID assigned, unless specifically configured to do so.

ID stability

Each matching group is defined by a unique master ID.

In MDM, the system always aims to reuse existing master IDs to maintain consistency.

When there is a request to merge records, one of the master IDs is retained and others are discarded. This decision is made either automatically using a matching rule or manually by a user.

Generic identifiers like UUID or NanoID cannot replace the master ID.

Rematching

Rematching in MDM is an operation that involves reassessing and potentially altering the matching status of records based on updated rules or changes in data. It can be triggered through various mechanisms within the MDM system:

Full or Partial Reprocess Batch Operation: This operation (a specialized type of load) reprocesses all or selected records in MDM storage by sending them to the MD Consolidation process.

When rematch is enabled, all rematch flag columns are set to true, causing the records to be both reprocessed and rematched. Currently, the rematch operation overrides manual matching decisions.
Rematch If Changed Configuration: This advanced matching configuration automatically triggers a rematch if specific columns listed in the Rematch If Changed section are altered, resulting in a recalculation of the matching for the affected records.

By default, this configuration does not override manual matching decisions. However, you can choose to allow it to override manual matches by setting the nme.match.rematchIf.removeManualMatch runtime parameter, see Runtime Parameters, section Process control.
Rematch Flag in MDM Core Service (processMatch): The ProcessMatchService allows external applications to modify record matching.

For example, the unIsolate function resets the eng_isolate_flag, making records available for further matching. Enabling the rematch flag will trigger matching recalculation based on the current configuration. Currently, the rematch operation overrides manual matching decisions.
Rematch Action in MDM Web App: In MDM Web App, splitting and merging instances are handled as overrides on the master_id column. To revert an instance record to its original state as defined by the configured matching and merging rules, a rematch of the instance record is required.

Currently, all types of rematch operations except Rematch If Changed configuration override all previous manual interventions, such as manual matches, splits, and resolved matching proposals. Consider avoiding those operations in the scenarios where manual changes have great importance.

Matching on master entities

In Centralized and Mixed MDM implementation styles, matching can also be performed on master entities. The master matching capability allows MDM to match records authored directly at the master layer, ensuring that they remain unique within the system.

It is also possible to match an instance record to an authored master record, even though it exists only at the master layer.

A specific configuration is required on the master entity to map attributes from the master layer to the matching step.

For more information about master matching, see Mixed Style in MDM, section Master matching.

Matching inactive records

By default, inactive records are included in the matching process and are treated the same as active records. However, in the mastering phase, inactive records are often filtered out and not used in the computation of golden records.

If a deletion strategy is employed, the inactive records are removed from the matching repository entirely and are not considered in any matching steps. This ensures that only relevant and active data contribute to the golden records.

The advantage of including inactive records is maintaining continuity. For example, if a client returns after a contract termination, the inactive record retains its master ID during the inactive period. In other words, when the client returns, this ID can be reused, preserving the customer identity.

Was this page useful?