Data_Model.docx

Copyright © 2016 Accenture All rights reserved. 2
Agenda
• Existing Master Data Solutions
• Introduction to SAP MDG
• MDM v MDG
• Basic Technical Settings
• Data Modeling
• SMT Mappings
Existing Master Data Solutions
• Standard Transactions-CRUD
• MDM

• Scope for MDG

Introduction to SAP MDG
• MDG Overview
• SAP Standard Data Models-0G, BP, MM
• Custom Objects

MDG Deployment Approach by SAP
MDG Deployment Approach by SAP

• Integrated with One • As a Standalone Hub SAP
ERP
– Pros – Pros
• Single Integrated SAP • Flexibility in Upgrade
instance
• Platform for broader MDM
• Less data distribution over- solutions heads
• Less maintenance overheads -
–
Cons
• Additional data distribution over-heads
– Cons
• Separate maintenance track
• Upgrade Strategy for standalone solution

Big picture: Hub vs. Co-existence
Factor Hub Co-existence
H/W Extra Hardware Cost Hardware Reuse
Industry
solutions/add-ons
Flexible Limited
Schema/Object
ERP/MDG unification
NA Object/Values
Superset
Data distribution Required NA
Upgrade flexibility Decoupled/independent Linked/depende
nt

Customizing/Configur
ation
Required NA

SAP MDG Architecture

MDG Solution Strategy

MDM v MDG

Basic Technical Settings
• Activation of Business Functions: MDG_APPL,
MDG_MATERIAL, etc..
• Workflow : User WF-BATCH Settings, SWU3
• Number Ranges: For Change Request, Type 1 entity key
• User Roles: TREX for Enterprise Search, SAP ALL to
WF-BATCH, Approver Roles
• Activation of BC sets: MM, 0G, BP (MDGIMG)
• Prefix for internal key assignment (MDGIMG)

Data Modeling
• Entity Types
1. Type 1
2. Type 2
3. Type 3
4. Type 4
All four types are explained in detail on next slides

Entity Types

Type 1:Changeable via Change Request; Generated
Database Tables
• Key Fields: Entity type itself, The Edition if your master
data is Edition dependent, Entity types related through
Leading relationship.
• Active Flag
• Additional Tables: Language dependent text,
Attachment, Set
• Non key fields
• Checkbox for Deletion

Type 2:Changeable w/o Change Request; Generated
Check/Text Tables
• Key Fields: Entity type itself, Entity types related through
Leading relationship
• Active Flag: N/A
• Additional Tables: N/A
• Checkbox for Deletion: N/A

Type 3:Not Changeable via MDG; No Generated
Tables
• Key Fields: N/A since no tables are generated
• Active Flag: N/A
• Non key fields: N/A
• Checkbox for Deletion: N/A

Type 4:Changeable via Other Entity Type;
Generated Database Tables
• Key Fields: Entity types related through Leading and
Qualifying relationship
• Active Flag
• Non key fields
• Checkbox for Deletion
Data Modeling
• Relationships

1. Leading
2. Qualifying
3. Referencin
g 4.
Foreign
Key
• Cardinalities
Leading Relationship
• Specifies the From-Entity type on a higher level than the
To-Entity type

• The From-Entity type is automatically taken as the key in
the generated tables
• A Leading relationship type is identical to a Qualifying
relationship type, except when the To-Entity type has a
Storage and Use Type of 4
• It serves the purpose of avoiding redundancy of single
common key field
Qualifying Relationship
• Specifies the From-Entity type on a higher level than the
To-Entity type
• The From-Entity type is automatically taken as the key in
the generated tables

• A Leading relationship type is identical to a Qualifying
relationship type, except when the To-Entity type has a
Storage and Use Type of 4
Referencing Relationship
• Specifies the From-Entity type as an attribute of the
ToEntity type
• It serves the purpose of avoiding redundancy of single
common optional field

Foreign Key Relationship
• Basic relational database concept
• Specifies that certain attributes or key fields of the
toentity type use the from-entity type as a foreign key
• Need to assign the relevant fields in the view Fields of
Foreign Key Relationships so that all key fields of the
from-entity type of a relationship are assigned
Cardinalities
• 1:N- This cardinality represents a mandatory relationship
in which one or more To-Entity Types can be assigned to
a From-Entity Type

• 0:N- This cardinality represents an optional relationship in
which any number To- Entity Types can be assigned to a
From-Entity Type
• 1:1- This cardinality represents a mandatory relationship
in which only one To-Entity Types can be assigned to a
From-Entity Type

Simplified

Data Modeling
• Access Class
1. Interface : IF_USMD_PP_ACCESS
2. Check/Validations
3. Derivations
4. Field Properties
5. Save Operation
6. Read Operation

SAP MDG – Integrated Data Model

Adaptations to the Data Model

Data Modeling & Custom Objects – Use Cases

Flex versus Reuse Model

Flex and Reuse Model
• To enable the master data governance process
MDG separates
• Active data – Ready to be used by applications, can be distributed
to client systems
• Inactive data – Not yet approved, currently part of a change
request
• Accordingly there are two separate storage
locations
• Active area – Holds the active data
• Staging – Holds the data during the change request processing
before approval

Flex and Reuse Model
• For optimal integration into SAP Business Suite
MDG allows two modes
• Re-Use active area (re-use mode) – Existing structures of
applications are used. For example, MDG for material makes use
of the MARA table in ECC
• Generated active area (flex mode) – Tables as defined in the MDG
data model are used to store active data

SMT Mappings
• Background
The SMT(Service Mapping Tool) is a program that
you can use in ABAP to fill a target structure with a
set of source structures.
The following are supported:
• Simple mappings
• Mappings with field transformations
• Complex transformations
• Field Checks
• Extended XML handling

SAP MDG System Walkthrough
• Transaction MDGIMG
• SMT Mappings

Thank You!
Questions?

Data_Model.docx

Recommended

Recommended

More Related Content

Similar to Data_Model.docx

Similar to Data_Model.docx (20)

Recently uploaded

Recently uploaded (20)

Data_Model.docx