SAP MDG Data Modelling

·       Data model is to define the structure of the data storage.

·       During Master data processing, a change request is used to store the data which is in process of changing in staging area.

·       The data model can define reuse area that is used for data storage after completion of change request.

·       In this case the system moves the data from staging area to a storage location using access class of the reuse area. This storage location is called active area.

·       In case no reuse area is defined, the same database table which is used for staging area, are also used to store active data.

·       Then no access class is involved, the system does not move the data to other system or any other table then MDG generated tables which is used as active area.

In simple term, Data Model is same like we define Entity Relationship Diagram on Paper. We Just define the structure of how data will get stored and what relationship they maintained with each other.

Area of Data Modelling

There are two area’s in Data Modelling of MDG.

1.       Staging Area

-          Staging area will store the Data which is in under governance process.

-          Data which is still is not active state.

-          Which is in under change request process.

-          Temporarily store the data before activation of Change Request.

 

2.       Active Area

-          Active area holds the permanent data which is activated under Change Request.

-          After all approval process and Completion of Workflow for CR the data get activated and it stored in this area.

Modes of Data Modelling

There are two modes of Data Modelling

1.       Flex Mode

-          In flex mode, after activation of data, it will get stored into MDG generated tables only.

-          USMD_ACTIVE = 1, which consider as active data and USMD_ACTIVE = 0 is consider as Inactive data.

-          Both data stores in same MDG Generated tables.

 

2.       Reuse Mode

-          In Reuse mode, we define Reuse area.

-          After activation of CR, the data get stores into permanent ERP tables like MARA, LFA1..

Data model consist of Entity, Attributes and Relationships which enable to model master data structure of any complexity in the system.

Definition

-          Collection of Entity which are logically related.

-          The system used data model to generate database tables depends on the structure of data model.

Entity Types

-          Entity is collection of attributes which are logically related.

-          The set of attributes of Business Object within a Data Model.

-          For Example, Vendor would have entity type for General Data, Company Code data, Purchase Order data or any other entity types.

-          It represents the type of master data within a Data model.

-          For each Entity type, we need to specify storage and uses type which define the properties of Entity Types in details.

-          You use the validity of entity field to specify for an entity type whether the validity of master data changes is restricted to editions.

Storage and Use Types

·       Specify whether and how Master data can be changed in MDG.

·       Indicates which database table generated by system.

There are four Storage/Uses Types

·       Type1: Changeable via Change Request; Generated database tables

·       Type2: Changeable w/o Change Request; Generated Check/Text Tables

·       Type3: Not Changeable via MDG; No Generated Tables

·       Type4: Changeable via Other Entity Type; Generated Database Tables

       Type 1: Changeable via Change Request; Generated database tables

·       The Master Data of this storage can be changed in MDG using Change Request.

·       System generate all necessary database tables.

·       We can only create change request for entity type of this SU type.

·       The key fields for this type of Entity is:

-          The Entity type itself

-          The edition if the entity type is edition dependant

-          The entity types which are assigned to this Entity type through Leading Relationship.

·       Assigning Data Element to this SU Type is Option. However, if the Data element is assigned and it consist value table then that value will get ignored and the values in generated database tables are independent of the value in check table or value table.

·       In this, we can assign simple attributes or can assign other entity types using relationship.

Type 2: Changeable w/o Change Request; Generated Check/Text Tables

·       Master data can be changed without change request.

·       System generate only text or check tables.

·       Mandatory assignment of data element.

·       The Value help assigned in data element is ignored.

·       The values in generated database tables is independent from the value table assigned to its domain.

·       In this, we cannot assign any attributes.

·       Key field will be Entity Type Itself and Entity Types related through Leading Relationship.

·       We cannot use this in following relationships.

-          In Referencing Relationship type, we cannot use this in To-Entity.

-          In Leading Relation with an entity type that has SU type 4 as To-Entity, we cannot use this SU Type as From-Entity.

·       Here, we can create check value entries using File Upload.

·       This check table will only will be generate in MDG layer (Staging table) not in S4HANA Active area.

       Type 3: Not Changeable via MDG; No Generated Tables

·       Master Data for this Entity types cannot be changed through MDG.

·       MDG doesn’t generate any table for this.

·       Mandatory assignment of Data Element.

·       System derives the available values from Domain of that Data Element as a Value table values or Domain fixed values.

·       In this, we cannot assign attributes.

·       No Key fields as not tables will generate.

·       We cannot use this in following relationships.

-          In Referencing Relationship type, we cannot use this in To-Entity.

-          In Leading Relation with an entity type that has SU type 4 as To-Entity, we cannot use this SU Type as From-Entity.

Type 4: Changeable via Other Entity Type; Generated Database Tables

·       Master data can be changed in MDG only with a change request of an entity type of SU Type 1.

·       This entity type needs to be in a relationship with relationship type Leading and assigned as To-Entity with SU Type 1.

Relationship Type	From Entity	To Entity
Leading	SU Type 1	SU Type 4

·       MDG Generate Tables for this.

·       If we enable edition, then edition number is the key field of the table.

·       We can assign simple attributes or assign other entity type using relationship.

·       We cannot assign Data Element to this SU Type.

Notes

·       If no Data Element is assigned to an entity type, you must use this entity type as a To-entity type in at least one relationship with the type Leading or Qualifying.

·       By assigning of Type of Key assignment, you specify for new entities created for an entity type whether the processors are to specify the key or whether this is to be assigned internally by system. We can also define that whether processors are permitted to later change these keys or not.

·       In MDG we can only maintain Change Request for SU Type 1 and SU Type 4.

Types of Key Assignment:

• Key Cannot Be Changed; No Internal Key Assignment

You need to enter the complete key when creating an entity. It cannot be changed at a later date.

• Internal Key Assignment Only

When you activate the change request (that is being used to create the entity), the system automatically assigns the key for the entity. Prior to the activation of the change request, the system creates a temporary key you can use to reference this entity within the change request. You cannot change the key.

• Key Can Be Changed; No Internal Key Assignment

You need to explicitly define the key of an entity you are creating. However, you can change it as long as the change request (in which the entity is being created) has not been activated. Once the change request is activated, you can no longer change the key.

• Key Can Be Changed; Internal Key Assignment Possible

This option is a combination of the two preceding options. Either the system can automatically assign the key of a new entity or a processor of the change request (in which the entity is being created) can create or delete the key.

• If a processor defines or changes the key, the system does not automatically derive the key when the change request is activated.

• If no processor explicitly defines or changes the key, the system automatically derives the key when the change request is activated. In this case, the automatically derived temporary key is used as the ID of the entity until the change request is activated.

Notes:

·        In 2^nd Option, Customization of activity Define Prefixes for Internal Key Assignment is optional.

·       In 4^th Option, Customization of above activity is mandatory. 

Relationships:

·       To map the structure of our master data management in the data model, we define relationship between individual entity types.

·       The relationship types determine whether one entity type is at higher level then another entity type or whether it is to be copied as an attribute of other entity type in the check table.

From Entity Type:

-          Specify the entity type to be use as starting point of a relationship.

To Entity Type:

-          Specifies the entity type to be used as the target of a relationship.

Relationship:

-          It defines technical name of a relationship between two entity types.

Types of Relationships:

·       Referencing

-          Form Entity Type will be attribute in To Entity Type.

-          That will be non-key field.

-          Cardinality 0: N are permitted.

-          Data Element can specify. However, this data element must have the same technical properties as the data element assigned to from-entity type.

 

·       Foreign Key Relationship

-          Certain attributes or key fields of the to-entity type use the from-entity type as foreign key.

-          Need to assign relevant fields in view Fields of Foreign Key Relationship, so that all the key fields of from-entity type of a relationship are assigned.

-          Cardinality 1: N is permitted.

 

·       Leading

-          From-Entity Type is at higher level than To-Entity Type.

-          From-Entity Type is added as a key field to To-Entity Type along with all assigned entity types with SU Type 4.

-          The Form-Entity Type which is in Leading relationship with To-Entity Type with SU Type 4, is the respective entity type which we can process the master data of the To-Entity Type with Change Request.

-          Cannot Specify Data Element.

-          Cardinality 1: N is permitted.

-          Cardinality 1: 1/1: 0 is also permitted if:

o   To-Entity Type has SU Type 1, no data element and no additional Leading Relationships.

o   To-Entity Type has SU Type 4 and no addition Qualifying Relationships.

·       Qualifying

-          Only use when From-Entity Type has SU Type 4.

-          Use to define additional key field in table.

-          System by default, transfer only key fields of the from-entity from the leading relationship.

-          Cardinality 1: N is permitted.

-          Cannot define Data Element.

Note: When you maintain Leading Relationship with type SU1 and SU4 type with 1: 1 cardinality, then there is no need to maintain qualifying relationship.

Define Entity Type to Be Used by Business Object Type

-          Business object type 899 is assigned to the entity type COA in both data model 0F and in data model 0G. However, during the replication of business object type 899, it must be clear for which entity type the data is to be replicated. Therefore, you specify here that the entity type COA from data model 0G is to be used for business object type 899.

Define Prefixes for Internal Key Assignment

-          In this Customizing activity you can define the prefixes of the temporary keys for entity types that support internal key assignments.

-          The system uses temporary keys for new entities until you activate those entities (or the change request).

-          If you use the setting Internal Key Assignment Only but do not define a prefix, the system uses the prefix $ by default.

Define Authorization Relevance per Entity Type

-          We can configure the authorization setting in this.

-          There are two option in this. Either we can use MDG general authorization or Predefined Reuse Active Area Authorizations.

-          By default, MDG framework will use System Predefined Active area authorizations.

-          For MDG general authorizations we have object ‘USMD_MDAT’.

-          For BP and MM, standard ERP authorization checks will be performed. Additional setting in this customizing activity is not supported.

Generate Data Model-Specific Structures

-          Here we can find the various technical structure for our data model entities, which is use in various different functionalities.

-          Following are the structure which is there in system for various operations

·       Structures for PDF-based forms

=>In MDG before versions, there were option to create master data using PDF forms. In that functionality, this structure was used.

·       Structures for the Service Mapping Tool (SMT)

=>This structure is used in Enterprise services. Which will help in moving data from active area to staging and vice versa.

·       Structures for mapping between the staging area and the reuse active area

=>This structure will be use to map fields between staging area and active area.

·       Structures for use in the Data Replication Framework (DRF)

=>This structure is used for Replication of data

=>We can assign this structure in Data Replication -> Enhance Default Settings for Outbound Implementations -> Define Business Objects and Object Identifiers -> Assign Key Structures to Object Identifiers.

·       Structures for Enterprise Search

=>This structure used in Enterprise search which is obsolete now.

=>Now a days we use HANA search

·       Structures for Field Control of Attributes

=>This structure will help in setting UI field properties like Mandatory, Read only, Hidden.

·       Structures for Field Properties of Attributes and Key Fields

·       Structures for Key Fields

·       Structures for Hierarchy Attributes

·       Structures for Data Extraction