The data model, entity by entity

Everything hangs off the model

UI configuration, change request types, BRFplus checks, staging tables and replication mapping are all configured against the data model. SAP delivers BP, MM and 0G (financial objects); custom models usually start with Z. Read the model as a schema definition: changing it changes generated database objects.

Entity types and attributes

An entity type is roughly a table with attributes (fields typed by data elements) and a key. Custom fields arrive as a model extension. In reuse mode the field must also exist in the target table (an append on LFA1, say) and be mapped; in flex mode MDG generates the storage. Same thinking as a Migration Cockpit field mapping.

The four storage and use types

Each entity type answers two questions: does MDG own this data, and can a change request change it? Getting it wrong is expensive: a reference modelled as type 1 invites governance of data nobody owns.

Try it: match the storage and use type

Relationships and cardinality

Leading makes one entity part of another's key (plant data cannot exist without the material). Qualifying adds a key part from another entity. Referencing checks an attribute against another entity, like a cost center's company code. Cardinality (1:N, 1:1) drives the UI and validation: "exactly one remit-to address" is a cardinality requirement.

Try it: which relationship?

A model change is a code change

Activating a data model generates staging tables, structures and, for flex entity types, active-area tables. After a change you regenerate, adjust UI configurations, review BRFplus checks and check replication mapping. Transport it, test with real CRs in flight, and never change keys of an entity with data without a migration plan.

Try it: model facts

Edit the model in MDGIMG → General Settings → ______Process ModelingData Modelingappend structureflexBAdIreusestaging/1MD/ → Edit Data Model. Activation generates ______Process ModelingData Modelingappend structureflexBAdIreusestaging/1MD/ tables in the ______Process ModelingData Modelingappend structureflexBAdIreusestaging/1MD/ namespace, and for ______Process ModelingData Modelingappend structureflexBAdIreusestaging/1MD/ entity types the active-area tables too. In reuse mode, a custom supplier field also needs an ______Process ModelingData Modelingappend structureflexBAdIreusestaging/1MD/ on LFA1.

Reading model data in ABAP

Use the model API so code reads staging or active data the way the framework does, without hard-coding generated table names. For read-only analytics on reuse-mode data, CDS views such as I_BusinessPartner or I_Product are often simpler.

DATA lo_model TYPE REF TO if_usmd_model_ext.

" 1. Get the model instance for data model BP
cl_usmd_model_ext=>get_instance(
  EXPORTING i_usmd_model = 'BP'
  IMPORTING eo_instance  = lo_model ).

" 2. Build a selection: entity BP_HEADER, key = partner number,
"    staging (with CR number) or active data
" 3. Call the read method (for example READ_CHAR_VALUE)
" 4. Process the result generically: the structure is generated

Let an assistant document the model

Export entity types and relationships, then ask for a data dictionary. Give it the raw export, not your memory.

Attached: two CSV exports from MDG data model ZSUP
(entity types with storage/use type; relationships with cardinality).
1. Produce a data dictionary: entity, type 1-4, key fields,
   parent entity, purpose (one line, mark GUESS if unclear).
2. List entities whose storage type looks inconsistent with
   their relationships, and say why.
3. Do not invent entities or fields that are not in the files.

Check yourself