What Is an MDG Data Model and Why It Matters
An introduction to the concept of an SAP MDG data model, explaining why it is the backbone of governance for business partner, material, supplier, customer, and custom domains.
Explanation
In SAP Master Data Governance, the data model is the structural definition of a governance object: the entity types, their attributes, the relationships between entities, and the mapping to the underlying business object (such as Business Partner or Material). Before any change request, workflow, or validation rule can be configured, a data model must exist that tells MDG what the object looks like and how its pieces relate to each other. Why this matters: MDG is not a generic workflow tool bolted onto SAP tables. It is a governance layer that understands the semantic structure of master data. When a consultant configures governance for business partners, the data model already exists as a delivered structure (using the standard Business Partner data model), because business partner governance is deeply integrated with the Business Partner architecture in S/4HANA. For custom objects, or for extending standard objects with additional attributes, you work with the data model layer directly. A data model consists of several building blocks. Entity types represent the main governed objects, such as Business Partner, Material, or a custom object like Cost Center Hierarchy Node. Each entity type has attributes, which map to fields on the underlying database or API structure. Entity types can have relationships to other entity types, such as a Business Partner having Addresses, Bank Details, or Roles as dependent entities. These relationships are important because they determine what data is edited together in a single change request and how the UI presents hierarchical or nested data. The data model also determines how MDG generates or consumes UI configuration. In the standard delivered content for Business Partner, Material, Supplier, and Customer governance, SAP ships a working data model, floorplan UIs, and business rules, so beginners typically work with pre-built structures rather than building models from scratch. Understanding the model, however, is essential because every troubleshooting task, every rule configuration, and every change request behavior traces back to how entities and attributes are defined. From a beginner's perspective, it helps to think of the data model as answering three questions: What object are we governing? What are its parts and sub-parts? And how do those parts relate to the real business object that eventually gets replicated to receiving systems. Without a correct mental model of this structure, governance configuration work such as rule assignment, validation setup, or workflow step configuration becomes guesswork. In S/4HANA, MDG for Business Partner, Customer, and Supplier is tightly coupled to the Business Partner model, meaning many attributes and relationships mirror the BP structure directly. In S/4HANA Cloud Public Edition, the governance capabilities are more constrained and configuration options are reduced compared to on-premise or private cloud, with SAP controlling more of the extensibility surface. This is an important distinction for beginners to internalize early: what is configurable on-premise may not be configurable, or may be configured differently, in the public cloud edition.
Real project scenario
A newly onboarded MDG functional consultant is asked to explain to a business stakeholder why adding a new custom field to the Supplier governance change request UI requires more than just adding a field to a screen. The consultant walks through the fact that the field must first exist on the underlying business object, then be mapped as an attribute on the relevant entity type in the data model, and only then can it appear in UI configuration and be referenced by validation or derivation rules. This explanation helps the stakeholder understand why the estimated effort for a seemingly simple field addition spans data model review, not just UI changes.
Common mistakes
• Assuming the data model is just a UI screen definition rather than the underlying structural and relationship definition. • Trying to add new attributes directly in UI configuration without confirming the attribute exists on the entity type first. • Not distinguishing between entity types, attributes, and relationships when discussing requirements with business analysts. • Assuming all governance domains (Business Partner, Material, custom objects) share identical extensibility rules across deployment options. • Overlooking that public cloud editions typically restrict data model changes compared to on-premise or private cloud.
Best practices
• Always confirm whether the object being governed uses a standard delivered data model or requires custom model definition before estimating effort. • Document entity type and relationship structure early in a project so business rule and UI teams share a common understanding. • Clarify deployment target (on-premise, private cloud, public cloud) before promising data model extensibility to stakeholders. • Use available data model review tools or documentation to confirm attribute existence before configuring rules or UI fields referencing it.
Interview angle
Interviewers often probe whether a candidate understands that MDG governance is built on a structured data model rather than free-form workflow screens. Be ready to explain entity types, attributes, and relationships in plain language, and to describe why standard objects like Business Partner ship with a pre-built model while custom objects require explicit data model definition work.