Understanding the SAP MDG Data Model Concept (Part 2)

In SAP Master Data Governance, a data model is not the same as the raw database table structure used by the application (for example, business partner tables or material master tables). Instead, the MDG data model is a governance-oriented representation of an entity type -- such as Business Partner, Material, Supplier, Customer, Financial data, or a custom object -- built specifically to support the create/change/mark-for-deletion lifecycle under change request control.

Why this separation matters: transactional systems are optimized for posting and reporting, not for staging unapproved changes, running validations, or triggering multi-step approval workflows. MDG introduces its own persistence and UI layer where a change is first captured as a 'staged' version of the entity, validated against business rules, routed through workflow, and only replicated to the active/consumption systems once approved. The data model defines exactly which entities, attributes, and relationships participate in this staged governance process.

At a conceptual level, an MDG data model consists of:

• Entity types: the governed objects, for example Business Partner, Material, Cost Center, or a custom domain object.
• Attributes: fields belonging to each entity, which can be simple fields, or grouped into sub-structures (for example addresses, bank details, valuation data).
• Relationships: links between entity types, such as a business partner having multiple addresses, or a material having multiple valuation areas per plant.
• UI structures: how these attributes are grouped and displayed in the Web Dynpro or Fiori-based governance UI.
• Change request relevant structure: which of these attributes can be changed under a change request, and how staged data differs from active data.

For beginners, the most important mental model is 'active area versus staging area.' The active area mirrors the state of record as seen by consuming applications (ERP, S/4HANA core tables). The staging area holds proposed changes that have not yet been approved. The data model governs what fields exist in the staging area and how they map back to the active area upon activation.

SAP delivers standard, pre-configured data models for common domains: Business Partner (customer/vendor unified model), Material, Financial master data (cost center, profit center, GL account), and others depending on release and deployment. In S/4HANA on-premise and private cloud, these standard data models can be extended. In public cloud editions, extensibility is more constrained and typically limited to key-user or SAP-provided extension mechanisms, with less direct access to core data model configuration.

Understanding the data model is foundational before touching change requests, workflow, or validation rules, because every later governance capability (business rules, duplicate checks, replication) is defined against specific entity types and attributes from this model. Misunderstanding which fields belong to which entity, or confusing the active versus staging structures, is one of the most common early mistakes for consultants moving from a pure ECC/functional background into MDG.

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. The consultant uses the active-versus-staging concept to explain that the change was captured against the Business Partner data model's staging structure, is pending approval in a change request workflow, and will only update the active area (and replicate downstream) once approved and activated.

• Assuming the MDG data model is identical to the underlying application table structure, leading to confusion when fields visible in the governance UI do not match transaction SE-level table fields.
• Treating 'saving' a record in the governance UI as equivalent to the change being live, without understanding the staging area concept.
• Not distinguishing between entity types (like Business Partner) and their sub-structures (like addresses or bank details) when discussing scope of a change.
• Assuming all standard data models are equally extensible across every deployment option, without checking whether the system is on-premise, private cloud, or public cloud.

• Always clarify with the business which entity types and attributes are actually in scope for governance before starting configuration.
• Use the standard delivered data models as the starting reference point and document any planned extensions clearly.
• Explain the active/staging distinction early to functional stakeholders to prevent confusion about when changes become effective.
• Confirm the deployment type (on-premise, private cloud, public cloud) before assuming a data model can be freely extended.

Interviewers often ask candidates to explain the difference between the active area and staging area in MDG, or why a governance data model is needed instead of governing tables directly. A strong answer connects the data model to the change request lifecycle and explains that governance requires an intermediate, validated state before data becomes authoritative.