Master Data Governanceadvanced

Advanced MDG Data Model Design and Extension (Part 7)

Key takeaway

Advanced guide to MDG data models, custom entities, extensibility, staging and replication impact. Step-by-step SAP Data Models guide with examples, practice…

Explanation

An MDG data model defines governed master-data structure and relationships. Extensions should represent real business semantics rather than becoming a place to copy every custom field from source systems.

Entity design affects workflow, staging, validation and replication. A field that belongs to a reusable address or organizational entity should not be duplicated in several places merely for UI convenience.

When extending standard domains, evaluate whether SAP extensibility already supports the attribute. Custom entities require ownership, keys and lifecycle design.

Every model extension should include downstream impact analysis. DRF replication, APIs, matching, search and consumers may all need to understand the new data.

Keep governance models simpler than source-system persistence whenever possible.

Real project scenario

A custom supplier attribute was added independently in several MDG entities, causing inconsistent values and complicated replication. Consolidating it into one governed entity removed duplication.

Common mistakes

Mirroring source tables one-to-one.
Duplicating the same attribute across entities.
Extending without replication analysis.
Ignoring search/matching effects.
Adding technical fields with no business owner.

Best practices

Model business semantics.
Reuse entities where appropriate.
Keep keys stable.
Analyze downstream consumers.
Govern every custom field owner.

Interview angle

Explain how MDG entity modeling affects governance, staging and replication.

Practice this lesson

Quick check

1. Scenario — A custom supplier attribute was added independently in several MDG entities, causing inconsistent values and complicated replication. In this Data Models situation, which response best addresses the underlying design risk?

2. A senior review of Extending and Customizing MDG Data Models with Custom Entities and Relationships finds this failure pattern: "Adding a field to the UI without first confirming it exists as a mapped attribute on the entity type in the data model.". Which corrective action is strongest?

3. What is the main purpose of a 'reuse entity type' in an MDG data model?

Interview questions

1. A senior architect is reviewing Data Models. The project situation is: A custom supplier attribute was added independently in several MDG entities, causing inconsistent values and complicated replication. What design changes, validation evidence and production controls would you require before approving the solution?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A consultant new to MDG is asked to explain to a business stakeholder why a change to a customer's address does not appear immediately in the ERP system after being saved in the MDG UI — explain Understanding the SAP MDG Data Model Concept. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.