SAP MDG (Master Data Governance)

Nayan R Patil
: +91- 9538602537

: nayanr10p@gmail.com
 Content

Custom Reuse Data Modeling in MDG

 Data Modeling
 Custom Reuse Data Model:
• Before we design the data model we need to understand how our database tables schema is and
database tables are related in backend.
• For example lets us take a material master data, how material master data tables are linked together in
backend.
• Go to SE11 T. code in SAP in the database table field mention MARA and click on display.
 Data Modeling
 Custom Material Master Data Model:
• MARA - Holds the Material master general data, here material number is the key field and the rest of
the fields are non key fields.
• The moment we create a material using MM01, the material number comes and sits in the MARA
table.
 Data Modeling
 Custom Material Master Data Model:
• When we extend a material to a plant then that material will be saved in MARC table
• MARC - Hold the material master plant data. In this table Material and Plant fields are key fields.
 Data Modeling
 Custom Material Master Data Model:
• If we extend a material plant data to a storage location then that material will be saved in MARD table.
• MARD - Holds the Material master plant storage location data. In this table Material, plant and storage
location fields are key fields.
 Data Modeling
 Custom Material Master Data Model:

ECC MDG
Schema/Domain Data Model
Database table Entity
Field Attribute

• A domain or schema in ECC is referred as a data model in MDG.

• A database table in ECC is referred as an Entity in MDG.
• A field in ECC is referred as an Attribute in MDG.
 Data Modeling
 Custom Material Master Data Model:
• If we look at the dependencies always MARD dependent on MARC, and MARC dependent on MARA.
• To consider MARA as a root table, the key field (Material) which is exist in MARA should also be there
in MARC and MARD, else we can’t extend material to a plant and storage location.

• Root/Primary table: MARA.

• Dependent tables : MARC; MARD.
• Key attributes : MARA - MATNR; MARC - MATNR, WERKS; MARD - MATNR, WERKS, LGORT.
 Data Modeling
Identifying Entity types and corresponding Relationships:
➢ Entity types:
Entity SU Purpose
Type
MARA Type 1 Root table
MARC Type 4 Dependent table
WERKS Type 3 Attribute

MARD Type 4 Dependent table

LGORT Type 3 Attribute
PSTAT Type 3 Attribute

➢ Key Attributes: MARA - MATNR; MARC - MATNR, WERKS; MARD - MATNR, WERKS, LGORT.

➢ How does system understand the entity types MARC is dependent on MARA and MARD is dependent on MARC:
• To achieve this we have to define a relationship between these entities.
 Data Modeling
 New Custom MM Data Model Design (Reuse):
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):

➢ T. code for MDG Configuration: MDGIMG

➢ Path for MDG Configuration: MDGIMG -> General Settings -> Data Modeling -> Edit Data Model
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
➢ Step1: Create new data model – MB: MDGIMG -> General Settings -> Data Modeling -> Edit Data Model ->
Click on New Entries -> Enter data model name and Description and save.

• This customizing activity provides an entry point for the entire list of data models available in the
system and the list of entities, attributes, and relationships.
• This enables you to extend or create new data models and activate them.
• The system uses the data model to generate database tables.
• This activity can be accessed using two different !MG paths, and each path offers a different way to
define or edit data models.
1. Edit data model functionality using SAP GUI
2. Configuration Workbench
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
➢ Step2: Define Implementation mode – Reuse or Flex
• To identify the implementation mode of a data model, use field “Active Area”
• Possible option for an Active Area:
1. Blank: Framework by default stores the Active Data in MDG Staging Area only: FLEX MODE.
2. MDG : Framework by default stores the Active Data in MDG Staging Area only: FLEX MODE.
3. Reuse Active Area: Framework stores the Active Data in Active Area of ERP or S/4 HANA using
Access class linked to Reuse Active Area: REUSE MODE
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
➢ Step3: Define Active Area by creating new custom access class and assign class to active area of data model
MB
• To define new custom access class run t. code SE24, enter the details as shown below and click on
create. Make sure that class name entered here is not exist in system.
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• This will be saved as a workbench request TR.
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• Access class establish the connection between MDG tables and active tables by implementing the ABAP
interface "IF_USMD_PP_ACCESS".
• Reading (active) of data from Re-use active area.
• Writing (active) of data from a CR to Re-use active area.
• Authorization checks for the Re-use active area.
• Once it is saved as work bench request system open the below screen,
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• Once it is activated, go to edit model and try to assign the access class. Check will system allow you to
assign it and save it. Even after creation of a access class we can’t able to see the active area for an
access class.

• Go to edit data model -> select data model “MB” and double click on node Reuse active area on the left
side of the edit data model screen.
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• Once it is saved, now we are able to see the active class in the active area F4 help, now try to assign the
access class and check will system allow you to save it.

• System giving an error, because we have just created the access class, but we did not implemented the
interface methods, to resolve this issue we have to do empty implementation for the created access
class.
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• Run t. code se24, open the access class and go to tab methods and start to implement
the methods as shown below.
 Data Modeling
 Steps to Create New Custom MM Data Model Design (Reuse):
• When debug mode opens just save the methods that’s it.

• After performing this activity for all methods, go to edit data model and assign the active area to
custom model “MB” and check will system allow you to save it.
 Data Modeling
 Step4: Create an Entity types and assign attributes.

• Once system display the entity types screen click on New entries and enter the details as shown below,
the below properties are only for SU type 1 entity “MARA”
 Data Modeling
• Enter Entity type as ”MARA” and select SU type as “1 Changeable via change request: Generated data
base tables” from drop down list, since MATNR is the key field which exists in dependent entities and
without material we can’t extend material to plant and storage location data.
• Validity/Entity: select as “No Edition”. Option “Edition” is used for Flex mode (MDG-F data model)
• Data Element: assign data element as “MATNR” for entity type1, then framework creates internally one key
attribute with the name of type1 entity i.e. MARA and stores the temporary key in this attribute. (If we do
not assign the data element to a type 1 entity, the system will not allow the user to assign a temporary key
to the type 1 entity and the system will use the actual number range configuration and generate the object
number during the CR process. These are not straightforward cases, some coding needs to done in the
backend to achieve this). Data element assignment only allowed for Type1, Type2 and Type3 entity.
• Key assignment: Temporary key assignment is based on this key assignment options.
 Data Modeling
• Key assignment: Temporary key assignment is based on this key assignment options.

Change Requestor Reviewer Approver Activation

request
CR - 1 1000 1000 1000 1000
CR - 2 $100 $100 $100 1001
CR - 3 1002 1003 1004 1004
CR - 4 $110 $110/1005 $111/1005 1005/1006

1. Key cannot be changed; No internal key assignment: During CR process, once a key (external number) is
assigned to a material by requestor at the requestor level then that key cannot be changed throughout the
process.
2. Internal Key Assignment only (I): During CR process, system assign an internal key ($) to a material at the
requestor level, then that key cannot be changed throughout the process. System will generate actual
material number after CR is activated. (It is applicable only for Entity Type1 )
3. Key can be changed; No internal key assignment (C): During CR process, once a key (external number) is
assigned to a material by requestor at the requestor level then that key can be changed at the different
levels in the process.
4. Key can be changed; Internal key assignment possible (B): During CR process, system assign an internal key
($) to a material at the requestor level, then that key can be changed at the different levels in the process.
 Data Modeling
• Language-dep. Texts: If you want to enable the language text table you can enable it.
• Attachments: Enable this, If we want to allow the attachments to an entity. System will generate internal
tables to store the attachments.
• Sets: Enable this, If we want to allow range of values to an entity.
• Search help:
1. If any data element of a field domain has the fixed value or check tables then the F4 helps to display the those
inputs by reading it from domain check table/fixed value.
2. If we provide search help to an entity, then it will overwrites the domain check table/fixed values and F4 helps
display the results based on the search help assigned to an entity.
• Source field short text, medium texts and long texts: Only applicable for Type 3 Entity
• Temporary keys: If we assign a temporary key to an Entity type 1 and initiate CR process, system will
automatically generates a temporary key. When framework needs to generate temporary key automatically
we have to configure number range.
• T. code SNRO- To define internal number range for temporary key.
• (Temporary Key or Internal key - Configurable) - Applicable only for Reuse Solutions.
 Data Modeling
• Temporary keys: T. code SNRO- To define internal number range for temporary key.
• Example of standard MDG-M model use the temporary key “MDG_BS_MAT” as shown below,

• Create a new Temporary key or we can use standard which is already exist in the system for material
entity.
 Data Modeling
• Active Area: This is optional at entity level, since the active area is assigned at data model level. If required
we can assign active area at Entity types level.
• Deletion: The purpose of this field is to allow framework to delete/ Non delete an entity type during the CR
process. For type 1 entity it is always “Deletion Not allowed”, since material is the key entity if we delete
the material header data, how framework creates a material. In case of type3/type4 entity it can be
assigned as “Deletion allowed”, since these are dependent entities and we can delete the data during CR
process.
• Example for dependent entities: When you start the CR process you entered material header data and plant data,
but before submitting the CR you identified that the material extended to some other plants, so here we have option
to delete the plant data and save the CR.
• Description, Structure/table and Field: These fields are for reference purpose only and do not affect the
functionality of the framework even though we do not enter the details.
• Structure X-Fields: It’s change flag structure, when you are calling any BAPI from the program you need to
pass the flag structures, it means which fields are changed during the current process accordingly the
respective business logic will be executed. If we want to update the structure we can update it.
• Generated: If the entity is autogenerated by the framework then this field will be checked.
 Step5: After maintaining all the required details for the fields, click on save. An Entity type “MARA” is
generated for data model “MB”.
• Follow the same process to create Entity type2, Entity type3 and Entity type4.
 Data Modeling
 Step6: Assigning the attributes to an Entity type1 “MARA”.
• To assign attributes to an entity type1 follow the path, select the data model “MB” → click on Entity types
node on the left side of the screen → select an Entity type to which we need to assign attributes and click
on an Attributes node which is below the Entity types node on the left side of the screen.
 Data Modeling
• Assign an attributes to an entity type1 “MARA” by clicking new entries as shown below,

• Key Field: We have option to define additional key fields for an Entity type 1 MARA. We can as many as
key fields.
• Req. Entity Field: We can maintain which field needs to be mandatory by checking this box.
• Curr/UOM field: We can see the example of handling currency/UOM attributes in an Entity type 4.
• Specifies the attribute that supplies the currency or UOM for other attribute that acts as a key figure.
• The attribute must have the data type currency or unit of measure.
• Search help:
• If any data element of a field domain has the fixed value or check tables then the F4 helps to
display the those inputs by reading it from domain check table/fixed value.
• If we assign any search help here, then it will overwrites the domain check table/fixed values. F4
help gives priority to search help assigned at attribute level and display the results.
 Data Modeling
• Assigning an attributes to an entity type1 “MARA”.
• No Existence check:
• Checking for the existence of a value entered in the field.
• If there are domain fixed values for the underlying data element, then we cannot select this checkbox
field, in this case system performs an existence check automatically.
• If we select this checkbox field, it deactivates the standard existence check for the value of the
attribute.
• If we assign any search help to an attribute, then the standard existence check does not take search
help into consideration, it checks only the values of the check table or fixed values of the domain of
the data element.
• Example: During creation of material either through CR or MM01, user will enter the details of industry sector
whatever is showing in the dropdown, if user try to choose/assign a value which does not exist in the dropdown
(value range) system will through an error, why because this industry sector has underlying domain level check
table.
• After maintaining all the required details for the attributes, click on save. This completes the assignment of
attributes to an Entity type “MARA” for a data model “MB”.
 Data Modeling
 Step7: Creation of an Entity type4 “MARC”.
• To create Entity type4, follow the same steps which we performed to create Entity type1. The below
screenshot shows the Entity type4 created.
 Data Modeling
• Enter Entity type as ”MARC” and select SU type as “4 Changeable via other Entity type: Generated data
base tables” from drop down list, since MARC is the dependent entity and without material we can’t extend
material to a plant.
• Validity/Entity: select as “No Edition”. Option “Edition” is used for Flex mode (MDG-F data model)
• Data Element: data element cannot be specified to the Entity Type4.
• Key assignment: for type4 entity always key assignment will be “Key cannot be changed; No internal key
assignment”.
• Active Area: This is optional at entity level, since the active area is assigned at data model level. If required
we can assign active area at Entity types level.
• Deletion: “Deletion Allowed”. Since it is dependent on other entity.
• After maintaining all the required details for the fields, click on save. An Entity type “MARC” is generated for
data model “MB”.
• As soon as we create type 4 entity, system shows some advanced errors related to relationships.
 Data Modeling
➢ Step 8: Relationships:
• Relationships can be defined only between two Entity Types (From Entity <Rel. Type> To Entity).

• Possible relationships based on above data model design

From Entity Relationship To Entity Cardinality Purpose
MARA Leading MARC 1:N Derive key attribute from MARA to MARC
WERKS Qualifying MARC 1:N Add as additional key attribute to an entity type 4
MARC Leading MARD 1:N Derive key attribute from MARC to MARD
LGORT Qualifying MARD 1:N Add as additional key attribute to an entity type 4

• All other non-key attributes becomes an attributes of respective entity types.

 Data Modeling
➢ Relationships:
• To maintain relationship select data model and click on Relationship node on the left side of the edit
data model screen

• In system when we define cardinality 1:1 for a relationship “MARA leading MARC”, system not
showing an error message to maintain qualifying relationship for entity type MARC. Because system
consider that the material is only creating for one plant, so no additional key required.

• When we try to save this relationship, system showing an error message to maintain Attributes for
entity type 4 MRAC. Refer next slide for assignment of attributes to MARC entity.
 Data Modeling
• Step9: Assign an attributes to an entity type4 “MARC”. To assign attributes to an entity type 4, follow the
same steps performed for typ1 entity by clicking new entries as shown below,

• Curr/UOM field: We can see the example of handling currency/UOM attribute in an Entity type 4.
• Specifies the attribute that supplies the currency or UOM for other attribute that acts as a key
figure.
• The attribute must have the data type currency or unit of measure.
 Data Modeling
• Curr/UOM field: We can see the example of handling currency/UOM attributes in an Entity type 4.
➢ Currency → (Amount + Currency format)
➢ Unit of Measure → (Value + Measurement unit)

➢ To maintain the Unit, click F4 help to add reference field for quantity field and save it.
 Data Modeling
➢ Step 10: Relationships
• In system when we define cardinality 1:N for a relationship “MARA leading MARC”, system showing an
error message to maintain qualifying relationship for entity type MARC. Because system consider that
the a single material can extend to “N” number of plants, so framework expecting user to define
additional key fields for an entity type MARC.

• To define a qualifying relationship for MARC, we have to create a type 3 entity as “WERKS”
 Data Modeling
 Step11: Creation of an Entity type3 “WERKS”.
• To create Entity type3, follow the same steps which we performed to create Entity type1. The below
screenshot shows the Entity type3 created.
 Data Modeling
• Enter Entity type as ”WERKS” and select SU type as “3 Not Changeable via MDG: No Generated tables”
from drop down list, since MARC is the dependent entity and without material we can’t extend material to
a plant.
• Validity/Entity: select as “No Edition”. Option “Edition” is used for Flex mode (MDG-F data model)
• Data Element: data element is mandatory since this itself acts as an attribute.
• Key assignment: for type3 entity always key assignment will be “Key cannot be changed; No internal key
assignment”.
• Active Area: This is optional at entity level, since the active area is assigned at data model level. If required
we can assign active area at Entity types level.
• Deletion: “Deletion Allowed”. Since it is dependent on other entity.
• After maintaining all the required details for the fields, click on save. An Entity type “WERKS” is generated
for data model “MB”.
• As soon as we create type 3 entity, system shows some advanced errors related to relationships for now just
ignore these errors. Since framework validates data model all together.
• We cannot assign attributes to Type 3 Entity since this itself acts as an attribute.
 Data Modeling
➢ Relationships:
• To define qualifying relationship for entity type MARC, created a new entity type “WERKS” as type 3
entity with data element, since WERKS is key field and itself acts as an attribute.
 Data Modeling
 Step12: Creation of an Entity type4 “MARD”.
• To create Entity type4, follow the same steps which we performed to create Entity type1. The below
screenshot shows the Entity type4 created.
 Data Modeling
• Enter Entity type as ”MARD” and select SU type as “4 Changeable via other Entity type: Generated data
base tables” from drop down list, since MARC is the dependent entity and without material we can’t extend
material to a plant.
• Validity/Entity: select as “No Edition”. Option “Edition” is used for Flex mode (MDG-F data model)
• Data Element: data element cannot be specified to the Entity Type4.
• Key assignment: for type4 entity always key assignment will be “Key cannot be changed; No internal key
assignment”.
• Active Area: This is optional at entity level, since the active area is assigned at data model level. If required
we can assign active area at Entity types level.
• Deletion: “Deletion Allowed”. Since it is dependent on other entity.
• After maintaining all the required details for the fields, click on save. An Entity type “MARD” is generated for
data model “MB”.
• As soon as we create type 4 entity, system shows some advanced errors related to relationships
 Data Modeling
 Step 13 Relationships:
• To maintain relationship for Entity Type 4 “MARD” follow the same steps which we performed for Entity
type MARC.

• In system when we define cardinality 1:1 for a relationship “MARC leading MARD”, system not showing an
error message to maintain qualifying relationship for entity type MARD. Because system consider that the
material is only creating for one plant, so no additional key required.
 Data Modeling
• When we try to save this relationship, system showing an error message to maintain Attributes for entity
type 4 MRAD.

• Step14: Assign an attributes to an entity type4 “MARD”. To assign attributes to an entity type 4, follow the
same steps performed for typ1 entity by clicking new entries as shown below,
 Data Modeling
➢ Step15: Relationships
• In system when we define cardinality 1:N for a relationship “MARC leading MARD”, system showing an
error message to maintain qualifying relationship for entity type MARD. Because system consider that
the a single material can extend to “N” number of plants and plants can have N number storage
locations, so framework expecting user to define additional key fields for an entity type MARD.

• To define a qualifying relationship for MARD, we have to create a type 3 entity as “LGORT”
 Data Modeling
 Step16: Creation of an Entity type3 “LGORT”.
• To create Entity type3, follow the same steps which we performed to create Entity type1. The below
screenshot shows the Entity type3 created.
 Data Modeling
• Enter Entity type as ”LGORT” and select SU type as “3 Not Changeable via MDG: No Generated tables”
from drop down list, since MARC is the dependent entity and without material we can’t extend material to
a plant.
• Validity/Entity: select as “No Edition”. Option “Edition” is used for Flex mode (MDG-F data model)
• Data Element: data element is mandatory since this itself acts as an attribute.
• Key assignment: for type3 entity always key assignment will be “Key cannot be changed; No internal key
assignment”.
• Active Area: This is optional at entity level, since the active area is assigned at data model level. If required
we can assign active area at Entity types level.
• Deletion: “Deletion Allowed”. Since it is dependent on other entity.
• After maintaining all the required details for the fields, click on save. An Entity type “LGORT” is generated
for data model “MB”.
• As soon as we create type 3 entity, system shows some advanced errors related to relationships for now just
ignore these errors. Since framework validates data model all together.
• We cannot assign attributes to Type 3 Entity since this itself acts as an attribute.
 Data Modeling
➢ Relationships:
• To define qualifying relationship for entity type MARD, created a new entity type “LGORT” as type 3
entity with data element, since LGORT is key field and itself acts as an attribute.
• Assigned a qualifying relationship and saved it as shown below.
 Data Modeling
 Step17: How to handle non-key attributes with same name/same data element:
• In the below example we can observe that non key attribute “PSTAT” exists in MARA, MARC and
MARD.

• When we try to assign an attribute “PSTAT” as a non key attribute in multiple entities, system showing
an error message
 Data Modeling
 How to handle non-key attributes with same name/same data element:

• If we want to include a non- key attribute with same name/same data element in multiple entities, in that
case we have to define the Referencing relationship by creating that attribute as an Entity type 3.

• Referencing relationship;
From Entity Relationship To Entity Cardinality Purpose
PSTAT Referencing MARA 0:N Add as a non - key attribute to an entity
PSTAT Referencing MARC 0:N Add as a non - key attribute to an entity
PSTAT Referencing MARD 0:N Add as a non - key attribute to an entity
 Data Modeling
 How to handle non-key attributes with same name/same data element:
• Create a “PSTAT as type 3 entity by following the same steps which we performed for other type 3
entity types.
 Data Modeling
 How to handle non-key attributes with same name/same data element:
• Maintain referencing relationship for PSTAT with Type1 and Type 4 entities i.e. MARA, MARC and
MARD.
• Only 1:N and 0:N cardinality allowed for referencing. 1:N cardinality is applies to referencing
relationships when the from entity type is required attribute of the to entity type, else we will use 0:N
i.e. From entity type is an optional attribute of the To entity type.
 Data Modeling
• Step18: After completion of all configuration activate the data model “MB” and save it.
• When we tried to activate the data model framework throwing an error to maintain a leading relationship
for type 3 entity “LGORT”
 Data Modeling
➢ Handling of Type 3 Entity with Multiple Key fields in underlying Domain’s Check Table:
• In the current design, LGORT’s domain level Check Table has key fields: “WERKS & LGORT”.
• To Check how many key fields are exist in domain’s check table, follow the below path
• T. Code -> Se11 -> Database table = “MARD” -> Click on display -> Key fields are: MATNR, WERKS,
LGORT
 Data Modeling
➢ Handling Type 3 Entity with Multiple Key fields in underlying Domain’s Check Table:
• To Check how many key fields are exist in domain’s check table,
 Data Modeling
➢ Handling Type 3 Entity with Multiple Key fields in underlying Domain’s Check Table:
• To Check how many key fields are exist in domain’s check table,
 Data Modeling
➢ Handling Type 3 Entity with Multiple Key fields in underlying Domain’s Check Table:
• To Check how many key fields are exist in domain’s check table,

• We need to link additional key fields of check table with core key field using relationship as shown
below
From Entity Relationship To Entity Cardinality Purpose
WERKS Leading LGORT 1:N Add as additional key attribute to an MARD entity
 Data Modeling

• Step19: After completion of the assignments, activate the Data model as shown below

• Data model activated without any issues. And active version status changed from None to “Same”
 Data Modeling
➢ Business Object type Code:
• In this Customizing activity, new BO Type Codes can be added for custom data models. For all standard
Data Models, there is no need to add any new BO Type Codes.
• IMG Path: IMG Path: MDGIMG → General settings → Data Modeling → Define Business Object Type
Codes

• Two or more entity types can be assigned to the same BO Type Code using IMG Path: MDGIMG →
General settings → Data Modeling Define Entity Type to be used by BO Type
 Data Modeling
➢ Business Object type Code:
• Assigning BO Type Code to Entity type at data model level using IMG Path: MDGIMG → General
settings → Data Modeling → Edit data model.
 Data Modeling
➢ Business Object type Code:
• Since MARA is the root entity type. Select the checkbox the entity type becomes the root node of the
assigned BO type code.

➢ Define Prefixes for Internal Key Assignment

• In a data model, when an entity type with internal number assignment is used, a temporary key
number range assignment is required.
• For example, the MATERIAL entity in the MM Data Model uses the MDG_BS_M number range object
and BP_ HEADER entity type in the BP Data Model uses the MDG_BP number range object for
temporary keys.
• SAP Master Data Governance has $ as the default Prefix, which can be changed if needed.
 Data Modeling
➢ Define Prefixes for Internal Key Assignment
• Using this Customizing activity, a prefix can be assigned to the temporary number generated for
internal number assignment scenarios to indicate that the generated number is a temporary number.

• Configuration path: MDGIMG → General settings → Data Modeling → Define prefixes for internal key
assignment

➢ Define Prefixes for Internal Key Assignment

• This Customizing Activity is used to determine whether the system uses predefined authorizations
from the Reuse Active Area(Default authorization check) or SAP MDG-specific authorizations using
authorization object USMD_MDAT.
• If the option to select SAP MDG-specific attributes is chosen, then configurations for authorizations at
the entity type level and authorization-relevant attributes need to be set up.
 Data Modeling
➢ Define Prefixes for Internal Key Assignment
• This Customizing Activity is used to determine whether the system uses predefined authorizations
from the Reuse Active Area(Default authorization check) or SAP MDG-specific authorizations using
authorization object USMD_MDAT.
• If the option to select SAP MDG-specific attributes is chosen, then configurations for authorizations at
the entity type level and authorization-relevant attributes need to be set up.
• If the reuse active area is checked, then settings made under Authorization for Entity Types and
Authorization Relevant Attributes views will be ignored.
• SAP S/4HANA and SAP ERP authorization checks are always performed for the BP and MM Data
Models; any additional settings performed under this Customizing activity aren't supported.
 Data Modeling
➢ Generate Data Model-Specific Structures
• We need to have a structure which can refer to staging area to define local Work Areas / Internal tables
for further processing.
• Staging Tables Vs Staging Structures:
• Staging Table and Staging Structure – Both are generated by the framework.
• Staging tables will be generated after the activation of data model.
• Staging structures can be generated manually using customizing activity.
• There are two ways to generate Staging Structures:
• Provide the Prefix and Package at Data Model Level -> Save & Activate the Data Model -> Staging
Structures are generated.
 Data Modeling
➢ Generate Data Model-Specific Structures
 Data Modeling
➢ Generate Data Model-Specific Structures:
• Generate the Staging Structures manually by using IMG Path: MDGIMG → General Settings → Data
Modelling → Generate Data Model Specific Structures.

• You need to manually select structure for each entity type by clicking on new entries.
 Data Modeling
➢ Generate Data Model-Specific Structures:
• Each data model and entity type can have the following structures in the Data Dictionary:
1. PDF-based Forms.
2. SMT with structures used for the configuration of enterprise services.
3. Mapping between Staging Area and Reuse Active Area.
4. Data Replication Framework.
5. SAP Enterprise Search.
6. Field control of attributes.
7. Field properties of Attributes and Key Fields.
8. Key Fields
• This Customizing activity is used to generate the preceding DM-Specific Structures.
• These structures need to be regenerated whenever a DM is changed.
• For all standard data models, these structures are delivered as well.
• When an entity type delivered by SAP is enhanced to include additional attributes, the system
automatically writes these attributes to Customizing Includes during the generation of data model-
specific structures.
 Data Modeling
➢ Assign Package and Define Package Groups:
• In this Customizing activity, a package can be assigned for the customizing includes used during Data
Model enhancements.
• IMG Path: MDGIMG → General setting → Data Modeling → Create and Edit Mappings → Define
Package Groups.
 Data Modeling
➢ Edit Data Model Functionality using Configuration Workbench:
• The Configuration Workbench is a Web Dynpro application that acts as an alternative to the Edit Data
Model Customizing activity via MDGIMG.
• Additionally, this presents data model details in a tabular format per entity type, and distinguishes
relationship information into outgoing and incoming relationships for each entity.
• IMG Path: MDGIMG → General setting → Data Modeling → Create and Edit Mappings → Define
Package Groups.
• The Configuration Workbench can also be accessed using Transaction MDGDT.
 Data Modeling
➢ Report 1: Visualize Data Model (USMD_DISPLAY_DATAMODEL):
• This report offers a hierarchical view of entity types and attributes in a data model. This report also
offers overview, detail view, and graphical display modes as well.
• Go to Se38 and enter the program name, and execute, after executing system asks for data model
provide data model and execute.
 Data Modeling
➢ Report 1: Visualize Data Model (USMD_DISPLAY_DATAMODEL):
• Another way to display the data model details is, go to edit data model select data model and click on
visualize data model option.
 Data Modeling
➢ Report #2: Data Model Generated Tables (USMD_DATA_MODEL)
• This report displays data model entity types and generated database tables. It's also possible to display
counts of active and inactive records for each of these tables.
• Go to Se38 and enter the program name, and execute, after executing system asks for data model
provide data model and execute.
 Data Modeling
➢ Report #3: Compare Data Model (USMD_COMPARE_DATA_MODEL)
• This report compares active and inactive versions of a data model and provides a list of comparison
results.
• Go to Se38 and enter the program name, and execute, after executing system asks for data model
provide data model and execute.
 Data Modeling
➢ Report #4: Delete Data Model (USMD_DELETE_DATA_MODEL)
• This report can be used to delete a data model. This functionality can also be triggered from the Edit
Data Model IMG node or the Configuration Work bench.
• Whenever we want to delete a data model first we have to delete active version of the data model
once the active version of the model gets deleted and the status of the data model changes to None at
Edit Data Model IMG node, then we can delete data model.
• Go to Se38 and enter the program name, and execute, after executing system asks for data model
provide data model and execute.
 Data Modeling
➢ Report #5: Adjust Staging Area of linked Change Requests (USMD_ADJUST_STAGING)
• For the selected data model, this report verifies whether any changes were made to the data model; if
yes, it adjusts the change requests that are in process per the changes made in the data model. This
report needs to be run in all relevant clients and target systems after data model changes.
• If we don’t perform the synchronization of a data model with staging tables, during creation/update of
a master data system will give dump.
• Go to Se38 and enter the program name, and execute, after executing system asks for data model
provide data model and execute.
 Data Modeling
 Another Possible data model design and Relationships:

From Entity Relationship To Entity Cardinality Purpose

MARA Leading MARC 1:N Derive key attribute from MARA to MARC
WERKS Qualifying MARC 1:N Add as additional key attribute to an entity type 4
MARA Leading MARD 1:N Derive key attribute from MARA to MARD
LGORT Qualifying MARD 1:N Add as additional key attribute to an entity type 4
WERKS Qualifying MARD 1:N Add as additional key attribute to an entity type 4
WERKS Leading LGORT 1:N Other key fields in the check table must be mapped
using relationships with Leading as the relationship
type
• All other non-key attributes becomes an attributes of respective entity types.
 Data Modeling
 Data Model structure:
• Hierarchical view of entity types and attributes for a data model.