DAMA - SAP MDG: Concept #4
Dzmitryi Kharlanau❗️The Problem
You see it everywhere:
5 fields for the same concept
10 reports with different totals
“We need to clean data manually after migration”
“The interface broke because the field wasn’t mapped right”
That’s not bad luck.
That’s bad modeling.
No matter how good your tools are — if the model is wrong, everything on top will fail.
🧠 What DAMA Means by “Data Modeling & Design”
This is the art of defining structure and relationships in a way that reflects business reality — clearly and unambiguously.
It’s not just about creating an ER diagram.
It’s about creating a language between systems, teams, and rules.
Three Levels of Models (per DAMA)
| Level | Purpose | Example (SAP MDG context) |
| Conceptual | What entities exist and how they relate — no tech yet | “Customer has Contacts and Addresses” |
| Logical | Attributes, keys, relationships — still system-agnostic | “Business Partner has roles, each with time validity” |
| Physical | How it’s implemented in tables, types, systems | “BP_CENTRL, BUT000, tables, SOA mappings” |
🔧 In SAP MDG: It’s Everywhere
MDG forces you to model. But if you don’t think before modeling, you’ll regret it.
| Modeling Area | What You Design | Real Example |
| Entity Types | What’s an object? Where does it live? | BP_CENTRL, MAT_PLANT, SUPPLIER |
| Attributes | What fields matter? Are they change-relevant? | REGION, TAX_NUMBER, PUR_ORG |
| Keys & Relationships | What defines uniqueness? What links what? | BP with multiple addresses, MARA to MVKE |
| Reuse vs Flex | Should I inherit from SAP table or go custom? | Reuse MARA vs build a Flex model |
| Change Relevance | What triggers versioning and approval? | Some fields ignored in CRs |
⚠️ What Happens When It Goes Wrong
You can't tell which material number is the real one
Your SOA messages break because the mapping doesn’t fit
Your CRs behave weirdly — fields don’t trigger changes
You duplicate data because uniqueness rules were vague
You redesign everything after rollout
That’s not a “system problem”.
It’s a modeling mistake.
📐 Design Principles That Actually Work
Model business meaning, not database columns.
If a field doesn’t make sense to a human, it won’t help the system.Define ownership per entity.
Know who defines it, who changes it, and where.Standardize field semantics.
Don’t let “Customer Type” mean 3 different things in 3 systems.Validate logic before coding it.
Use logical models to test understanding between business and IT.Treat your models like contracts.
Once published — don’t break them without impact analysis.
🧩 When This Becomes Critical
In system migrations
In integration projects
In master data harmonization
In regulatory reporting
In SAP MDG rollout
💬 Bottom Line
If you model clearly, everything else becomes easier — validation, replication, integration.
If you model vaguely, you’ll be fixing forever.
Modeling is not just a technical step.
It’s how you turn chaos into logic — and logic into trust.
Subscribe to my newsletter
Read articles from Dzmitryi Kharlanau directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Dzmitryi Kharlanau
Dzmitryi Kharlanau
SAP Logistics Consultant with 10+ years of experience in SAP SD, SAP MM, SAP LE, and SAP IS-Automotive. Skilled in SAP system support, integration, and process improvements. Achievements ✔️ Delivered custom logistics solutions, overseeing the entire process from concept to go-live. ✔️ Achieved SLA compliance in JIT environments, managing tasks from requirements to release independently. ✔️ Resolved complex issues swiftly, minimizing downtime and optimizing efficiency. Interests: Motivated to work with 🔧 S/4HANA SD, MM, BTP, and ABAP, taking responsibility for end-to-end solutions.