DATA ARCHITECTUREIdentity

Master Data Management (MDM)

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

⏱ 18 min readTopics chapter readerLevel · Specialized & Applied
01 · Orientation

What You'll Master Here

Many source records → resolve which are the same entity → merge by survivorship rules → one golden record with lineage back to its sources.

⏱ 4 min · Topic 1 of 8

Halbeck Industrial buys from four companies. Its ERP, its procurement portal and its quality system between them hold ten supplier records, and no system can say which of the ten are the same company. Master Data Management (MDM) is the discipline of turning that into one trusted, authoritative record per real-world entity.

Work the four business questions below before reading on. Three of them come out wrong because records describing one company stayed separate; the fourth comes out wrong because two separate companies were treated as one. Those errors pull in opposite directions, and every decision in this chapter is a choice about where to sit between them.

Core mental model

Many source records → resolve which are the same entity → merge by survivorship rules → one golden record with lineage back to its sources.

Why it matters

Every cross-system number — spend, exposure, a single customer view — is wrong if one entity appears as several records, or if two entities appear as one.

master data
Core business entities shared across systems: customers, products, suppliers, plants.
golden record
The single, trusted, merged representation of one real-world entity.
identity resolution
Deciding which source records refer to the same real entity (also entity resolution).
survivorship
The rules that pick the winning value for each field of the golden record.
Halbeck Industrial · supplier master across erp_ap, procure and qms

Ten source rows describe four real companies. Ask a business question and watch the two answers separate.

What each system holds
  • erp_ap — 4 rows. Invoices, bank details, VAT and registration numbers.
  • procure — 3 rows. Sourcing contacts, current site addresses, categories.
  • qms — 3 rows. Audit outcomes and approval status. No registration numbers at all.
The four real companies: Nordvik Precision Ltd · Nordvik Precision Tooling Ltd · Calderbrook Seals and Gaskets Ltd · Pennine Toolroom Services. The first two are separately registered businesses.

How many suppliers do we buy from?

Answer from the source rows10 supplierscount(*) across the three source supplier tables
Answer from the golden records4 supplierscount(*) on the golden supplier table
Failure: records that are one company stayed manyTen rows describe four companies. Nordvik Precision appears in all three systems; Calderbrook appears in all three and twice inside the ERP, because Finance re-onboarded it in 2026 instead of finding the 2023 record.What it costs. The supplier-rationalisation programme is scoped against ten relationships, six of which do not exist. Every per-supplier average — spend, lead time, defect rate — is divided by 2.5 times too many denominators.
Both directions are errors, and they pull against each other. Everything that follows in this chapter is a way of choosing where to sit between them.
Common mistake

Assuming each source system's supplier id is the real, shared identity. The same company counts as several suppliers; every cross-system metric is inflated and contradictory.

Assuming the only MDM error is failing to merge. Merging two legally distinct entities fuses their money, credit and approvals — the harder error of the two to unwind.

Better habit

Treat shared core entities as master data needing one golden record.

Resolve identity before computing any cross-system metric.

Keep lineage from each golden record back to its sources.

The big idea

MDM answers "who or what is this, really?" across systems. It is the cross-system cousin of the keys-and-identity chapter: identity, but when no shared key exists.

Review Keys & Identity (ch3)
How to study this chapter

One dataset runs through every widget: the same ten Halbeck records get standardized, blocked, scored, merged, mis-merged and unmerged.

Remember this

MDM produces one trusted golden record per entity via identity resolution and survivorship — and it fails in two opposite directions, only one of which is cheap to fix.