Is master data the same as metadata?

No. Metadata describes data, such as a field's meaning or origin. Master data describes the business entities that activities refer to.

Must all master data be centralized?

No. Implementation can involve multiple systems with agreed identities and governance. The arrangement must make authority and synchronization understandable.

Can AI create master data automatically?

AI can suggest matches or extract attributes, but uncertain identity decisions and conflicting evidence still need suitable controls and review.

AI Glossary / Data engineering and architecture / Beginner

Master data

Definition

Master data describes the core entities that an organization repeatedly refers to, such as customers, products, suppliers and locations. It gives those entities shared identities and descriptive attributes so that different activities can refer to the same thing consistently. Master data management is the ongoing work of governing and maintaining that data.

What it means

A product description and identifier can be reused in ordering, stock management and customer support. The individual order is a transaction; the product it refers to is a business entity. A controlled list of country codes is reference data, while an organization's supplier records are master data.

These distinctions concern purpose, not a particular file format. Master data can reside in several systems, and an organization must decide which sources have authority for which attributes. Calling a table the master does not establish that its contents are correct. Shared identities also require agreed definitions: a customer account, a household and an individual customer are different things.

How it works

Teams first define the entities and the identifiers used to distinguish them. They inventory relevant source systems and map local records to shared identities. Matching may use exact identifiers or combinations of attributes, with review for uncertain cases.

When sources disagree, documented rules determine how to resolve the conflict or route it to a responsible steward. For example, a verified product specification might have authority over an older imported description. An unresolved discrepancy should remain visible instead of being silently overwritten.

Approved changes then reach consuming applications through an appropriate integration process. That process needs to handle delays, failed updates and records that were incorrectly merged. A consolidated record, sometimes called a golden record, is therefore a governed representation with provenance, not an infallible observation of reality.

Three practical examples

1. Product support: A service agent looks up a replacement part using the same product identifier that the warehouse uses. Different marketing names do not create separate physical products by accident.

2. Supplier coordination: Purchasing teams link their local supplier accounts to a shared supplier entity. Separate delivery locations remain distinct attributes or related entities rather than being mistaken for duplicate organizations.

3. AI recommendations: An analyst aligns product identities across browsing and purchase datasets before training a recommendation model. The alignment prevents one item from appearing as several unrelated products, although it does not establish that the training data is representative.

Think of it this way

Think of master data as the cast list for a long-running play. Many scenes refer to the same characters, while the script records what happens to them. A consistent cast list helps everyone understand those references.

The analogy has limits. Business entities can change names, split, merge or have uncertain identities. Maintaining their records requires evidence and history, not merely choosing a convenient spelling.

Worked example

Imagine three source records: CRM record C17 names Cedar Studio at address A; support record S42 names Cedar Studio at address A; billing record B09 names Cedar Studio at address B.

Suppose a verified registration identifier confirms that C17 and S42 describe the same organization. They can map to shared entity E1. B09 has a different verified registration identifier and maps to E2, despite the identical name.

There are three source records but two entities. Merging solely on the name would incorrectly produce one entity and combine unrelated histories. Conversely, refusing every cross-system match would preserve three apparent entities.

The useful output is the two entity records plus the source-to-entity mappings and the evidence supporting them. If address A changes later, historical transactions may still need their original delivery address; updating the current master address should not silently rewrite those past events.

Illustrative case study

Fictional case: Entity Meadow sells equipment through a website and a service desk. Its team discovers that a compact pump appears under two product codes after a catalog migration. An AI search assistant consequently returns two descriptions with conflicting dimensions.

A product steward checks the original specification and confirms that the codes refer to one model. The team retains both source codes as aliases, records which specification is authoritative and updates the assistant's retrieval dataset.

It also keeps a similar-looking larger pump separate. The lesson is that reconciliation needs product evidence; approximate name similarity alone cannot decide identity. This example illustrates a workflow, not a measured business result.

Common misconceptions and mistakes

Master data is not permanently static. Organizations relocate, products change and relationships expire. Changes need effective dates when their timing matters.

A single database does not automatically produce shared definitions. Two departments can disagree about what its customer field represents.

Deduplication is not simply deleting repeated-looking rows. False merges can be harder to notice than duplicates because they create plausible but incorrect combined histories.

Nor does an AI matching score replace ownership. Someone must define acceptable evidence, handle exceptions and provide a way to reverse mistakes.

Business use

Start with a concrete cross-system problem, such as inconsistent product identities in support searches. Define the entity boundary, source authority, update responsibility and expected consumers before buying a tool.

Useful measures include unresolved identity conflicts, confirmed false merges and the time taken for approved changes to reach applications. Assess them against a reviewed sample. A falling record count alone cannot demonstrate improved quality.

Check your understanding

Two customers have identical names. Should their records automatically become one master customer?

Answer: No. Names alone are insufficient evidence of identity. Check reliable distinguishing information and preserve uncertainty until the match can be justified. A shared master identifier should represent an established relationship, not create one by assumption.

Related terms

Data Quality
Master data management
entity resolution
reference data
transactional data
data stewardship
data lineage
slowly changing dimension

Learn next

Learn entity resolution next to understand matching evidence and false merges. Then study data stewardship to assign responsibility for disputed attributes. Finally, explore slowly changing dimensions to see how analytical systems preserve historical descriptions alongside current master data.

Sources

IBM, What is master data management? https://www.ibm.com/think/topics/master-data-management — Primary vendor overview consulted for master entities, related data categories and governance context. The identity exercise, fictional case and implementation questions are original teaching material, not reported IBM results.

Previous: Master-checker Next: Master sample