Master Data Management (MDM)
MDM - what the exam tests
This domain tests the Informatica MDM hub lifecycle: how records move from landing through staging to the base object, how match and merge produce a trusted record, and how survivorship and trust resolve conflicting values across source systems.
Core rules
- Flow: landing tables receive source data, staging tables hold cleansed and standardized rows, the base object is the master table, and the hub store serves consolidated records. Batch jobs move data between layers.
- Every base object row carries system columns: ROWID_OBJECT (hub row identifier), PKEY_SRC_OBJECT (source record key), HUB_STATE_IND (record state), plus consolidation indicators.
- Match rules use exact or fuzzy strategies with per-column weights and a threshold; candidate matches become match groups and potential matches for steward review.
- Merge creates a consolidated golden record; trust scores are evaluated per cell to decide which source value survives. Trust can derive from source-system priority, validation rules, or manual override.
- Consolidation is not automatic for every update - a record flagged for re-consolidation must be processed again by the consolidation job.
Worked example
A CRM record and an ERP record match on tax ID plus a fuzzy name score of 92 against a threshold of 85. The CRM name carries cell trust 8, the ERP name 6, so the consolidated name comes from CRM. The ERP address has the higher address trust, so it survives for that column. Reasoning: trust is evaluated column by column, not record by record - the golden record legitimately mixes sources.
Traps
- Assuming every match merges automatically; potential matches go to a steward.
- Treating PKEY_SRC_OBJECT as unique across the hub - it identifies the source record, not the hub row.
- Changing trust and forgetting to re-consolidate, so the golden record keeps the stale value.