Understanding Entity Relationships in SAP MDG

There are four relationship type in SAP MDG. In this blog we will discuss the first three with samples. I'll cover foreign key relationship in a later blog with an accurate sample.

But, before we proceed with the implementation, let me outline the "business scenario" that we will use to understand entity relationships:
Rental Car Sample Scenario (Why fictitious scenario?): A Rental car agency (lets call it PRITZ) buys new cars on a regular basis, to maintain/expand their fleet of cars at various rental office locations, across the country. We will create a MDG solution to maintain the master data for the cars in the fleet. When PRITZ buys new types of cars (or sells existing cars), a business user (say Lisa) in PRITZ's headquarters will use our MDG solution to add the new car types into the system. If PRITZ decides to buy 80 Toyota Prius 2019 models for 13 rental locations, Lisa will use our MDG solution to add Toyota Prius as a new car type in the system and trigger the change request process. The change request then goes through the various departments of Maintenance, Operations and Sales. Master Data Stewards at each of these department will enhance the data with the right attributes and approve them. It is also important to point out that, MDG solution is to maintain the "master data" of Car type. Every time a new purchase order is created to buy additional cars (or an existing car type), it a "transactional data" in the system.

In the reference implementation of the above scenario, we have following relationships. BTW, the entire end to end implementation of this MDG solution can be viewed here.

But, to start with, the data model will look something like this.



Leading: In our example here, it is the a relationship between a RCAR (SUType1) and SUType4 entities. The key, RCARID, of RCAR is automatically added as the key for the SUType4 generated table

Qualifying:

Referencing:

It is important to note that the MDG eLearning series is being constantly updated. It is a one time fee to get life time access to the training material and it is constantly updated to add additional MDG scenarios.

Why use a fictitious scenario rather than a real world ERP scenario?
We decided to use fictitious scenario for several reasons. We go through the entire end to end realization phase with this sample scenario for custom object. This helps showcase all the capabilities of MDG. With a ERP scenario, it would help to know the master data object well. The simple rental car business scenario is relatively very simple to grasp. A MDG beginner can spend more time focussing on the details of MDG and its underlying technologies. As opposed to getting bogged down with Material, Plant, MRP, BOM, Routing and other details.
We will cover scenarios involving MDG Material solution in later additions of the eLearning content.

MDG Data Modeling basics.

Data modeling the first step with any mdg implementation. As with every other aspect of MDG, data modeling process is very flexible and generic. The flexibility ensures that MDG can address a variety of customer requirements and data model design specifications.

This blog highlights various rules and reasons behind the data modeling decisions. For an end to end solution implementation, check out the eLearning sessions posted here.

Once the data model is implemented in MDG and activated, the system automatically generates the underlying tables and structures. When the end users create or change data from the UI, the data is persisted in these generated tables.

Data Model for Z4 (a test data model):

The corresponding generated tables for Z4:

There are a variety of configuration options when creating an Entity. Each of the options affect the final MDG solution in a unique way. In this blog we consider the configuration options available with mdg data modeling and their significance. 

First step in mdg data modeling is to create a SU Type 1 (Storage and Usage Type One) entity. To draw an analogy with MDM, SUT1 in MDG corresponds to the Main Table in MDM.

For a simple Type1 entity, the Storage Type, Data Element and Description are the main fields. Leave the others as defaults. Data Element is a optional field here. When provided, the Data Element is a key field in the generated table.

For this Entity, I have added one attribute of type Z3COMMENTS. Pl. note that the Data Elements and Domains used in MDG Data Modelling already exist as part of a ERP solution or are created (using SE11 tcode) .

This is a simple data model with a single Entity. Suggested next steps:

1. The four Entity Types in MDG
2. Understanding relationship in MDG
3. Key Assignment and Deletion have a dependency on each other. These dependencies are enforced by the system. Try changing the default values to observe the specific dependencies.

Following three error messages show up when I try changing the Key Assignment to "Key Can Be Changed; Internal Key Assignment Possible".

4. Try creating the SUType1 entity with out the data element. Instead add an attribute of this type (of data element) to the Type1 entity. See the resulting change in the schema of the generated table.

Cheers!