The MDM data model for product catalogs, explained
A practical, catalog-team explanation of mdm data model, with the governance concepts to borrow from MDM and the heavy program work mid-market distributors can skip.
A product catalog does not become mastered because every source has been squeezed into one wide table. The model must represent which records describe a stable product, which are sellable or stockable variants, how suppliers and identifiers connect to them, and why a field value won. An MDM data model makes those decisions explicit enough to validate and synchronize.
The practical definition
An MDM data model for product catalogs defines the entities, relationships, attributes, and survivorship rules behind the product record. It should cover item, product, variant, supplier, brand, taxonomy, UoM, identifiers, assets, and channel content without pretending every field has the same owner or the same trust level.
The core entities and their boundaries
| Entity | Owns | Must not be confused with |
|---|---|---|
| Product | Stable commercial identity, brand, manufacturer, family, and shared technical facts | An ERP item, supplier offer, or channel listing |
| Variant | A meaningful option such as size, voltage, finish, or pack level | A duplicate description or regional alias |
| Item | A purchasable, stockable, or sellable ERP representation | The customer-facing product identity |
| Supplier | Legal-entity identity and source-authority context | A supplier location, feed, or supplier item number |
| Supplier offer | Supplier part number, price, lead time, MOQ, and purchasing pack | The manufacturer product it references |
| Taxonomy node | A governed classification position and its applicable attribute schema | A free-text category label from a source file |
| Identifier | A typed value, issuer, scope, and validity dates | A universal primary key |
| Asset | Document or media identity, version, role, locale, and evidence | An unversioned URL stored in a product column |
| Channel record | Channel-specific copy, assortment, and publishing state | The canonical product or operational item |
Keeping these boundaries prevents a supplier’s case offer from becoming a new product, a SAP plant extension from becoming an independent item, or an ecommerce title from overwriting the canonical technical description.
Relationship map: how the records connect
A practical relationship model looks like this:
The cardinality matters. One product can have many variants, one supplier can make many offers, and one item may carry several identifiers over time. Put validity dates and relationship roles on the links; otherwise a replacement MPN, acquired brand, or changed pack hierarchy destroys history.
Attribute schema: model values, not just columns
Each governed attribute needs more than a field name. Store its data type, unit or controlled vocabulary, category applicability, cardinality, required status, validation rule, and display label separately from the observed value. The value itself should carry source, extraction time, confidence, reviewer state, and effective dates.
| Attribute type | Model requirement | Example |
|---|---|---|
| Identifier | Type, issuer, scope, normalization, uniqueness rule | MPN `BV-SS-050-FNPT` is unique within manufacturer, not globally |
| Measured value | Numeric value plus normalized unit and original assertion | Working pressure `1,000 psi`, source stated `68.9 bar` |
| Controlled value | Vocabulary ID plus source label mapping | Body material `stainless-steel-316` from source label `SS316` |
| Relationship | Target entity, role, cardinality, and effective dates | Valve supersedes an older manufacturer part |
| Channel content | Locale, channel, version, approval, and fallback | German marketplace title distinct from canonical name |
| Evidence | Source document, page or cell locator, timestamp, and hash | Pressure rating traced to datasheet page 2 |
The 58 fields of a complete product record provides a useful starting inventory, while schema mapping explains how source fields connect to this governed model.
Survivorship rules by attribute type
A single global “system priority” is too blunt. Survivorship should run per attribute and consider source role, specificity, freshness, validation, and confidence.
| Field | Example winning rule | Why |
|---|---|---|
| Manufacturer part number | Manufacturer evidence wins; normalize formatting but retain the asserted form | A reseller alias cannot redefine manufacturer identity. |
| Purchasing UoM | Approved ERP item or active supplier contract wins for that offer | The correct value is relationship-specific, not a universal product fact. |
| Technical rating | Current manufacturer datasheet wins after unit and range validation | Technical authority and document version matter more than import recency. |
| Marketing title | Approved channel-and-locale record wins | Copy can legitimately differ without changing product identity. |
| Taxonomy | Steward-approved canonical classification wins; source labels remain mappings | Supplier categories are hints, not the target hierarchy. |
| Compliance status | Evidence valid for the product variant, market, and date wins | A certificate for one variant or region must not leak to siblings. |
Ambiguous ties should create an exception, not a silent overwrite. Store both candidate assertions and the decision evidence so a later source revision can be evaluated without reconstructing the old import.
Example record: valve, pack, supplier offer, and evidence
For manufacturer product BV-SS-050-FNPT, the product entity owns brand, valve type, material, connection size, and rated pressure. An each-level variant maps to an ERP stock item; a box-of-10 item points to that variant through a packaging relationship with conversion factor 10. Supplier SUP-1042 provides offer VLV-77104, with its price, MOQ, and lead time attached to the offer rather than copied onto the product.
The pressure rating assertion links to the current manufacturer datasheet, while the purchasing UoM links to the supplier contract and approved ERP item. A storefront title remains a channel record. This structure creates one canonical product record without pretending that price, packaging, technical evidence, and marketing copy share an owner.
Implementation sequence
- Choose entity boundaries
Write down what makes a product, variant, item, supplier offer, and channel record independently identifiable. Test the definitions against pack sizes, replacements, and multi-supplier sourcing.
- Define typed relationships
Add role, cardinality, effective date, and provenance to product-to-item, product-to-supplier, hierarchy, and supersession links.
- Specify attribute contracts
For each product family, define types, units, vocabularies, required fields, applicability, and validation rules before mapping source columns.
- Encode survivorship and exceptions
Set field-level source authority and confidence thresholds. Route unresolved conflicts to reviewers and record why a value was approved.
- Synchronize projections
Publish only the fields each ERP, PIM, marketplace, or analytics system needs while retaining the richer canonical graph and evidence centrally.
How Claro applies the model
Claro resolves incoming supplier records into product, variant, item, and offer roles instead of flattening them into duplicate rows. It maps attributes to the applicable category schema, evaluates field-specific survivorship, retains each assertion’s provenance, and produces system-specific projections for ERP, PIM, and channels. The model remains inspectable: a steward can see both the winning value and the evidence behind rejected candidates.
The broader product master data management guide explains when to adopt these controls and how they fit alongside ERP, PIM, PLM, and content systems.
Related data-model resources
Guide
58 Fields of a Complete Product Record
Inventory the identity, technical, commercial, and governance fields a model may need.
Glossary
Canonical Product Record
Understand the governed record produced by identity and survivorship decisions.
Glossary
Schema Mapping
Map supplier fields and vocabularies into a target attribute model.
Glossary
Master Data Management
Place the product model within the wider MDM discipline.
FAQ
Does an MDM data model have to be a graph?
No. Relational tables can represent the model, provided products, variants, items, supplier offers, identifiers, attributes, and evidence remain distinct and their relationships are typed. The important design choice is preserving entity boundaries and history, not selecting a fashionable database.
Where should survivorship rules live in a product data model?
Store them by attribute or attribute class, with source role, validation, freshness, confidence, and exception behavior. A manufacturer can be authoritative for a pressure rating while an ERP owns an approved purchasing unit and a PIM owns localized channel copy.
Claro
Stop maintaining this by hand
Claro keeps product and supplier data trusted as catalogs change — matching, deduplication, enrichment, and validated write-back into the systems you already run.
Book a demo