Show TOC

Background documentationConcept of the MDG Data Modeling

 

A data model in Master Data Governance is comprised of various elements (entity types, attributes, and relationships) to enable you to model master data structures of any complexity in the system. These elements are described below.

The system uses the data model to generate database tables for storing the data you enter when managing the master data. Which key fields and non-key fields these database tables contain depends on the structure of your data model.

Note Note

This documentation supplements the information that is available in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Data Modeling Next navigation step Edit Data Model End of the navigation path. Therefore, this documentation only covers the areas of the data model that require more background information for better comprehension.

End of the note.
Entity Types

You define entity types to model different types of master data in your data model. The system generates for each entity type the database tables that are needed for processing the master data in Master Data Governance. You can define the following properties for an entity type:

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

    • Edition

      When you create a change request to process entities for entity types with this validity concept, you need to assign the new change request to an edition.

      The corresponding change request type must reference an edition type.

      With this validity concept, the edition field is included in the database tables.

    • No Edition

      When you create a change request (to process entities) for entity types with this validity concept, you do not assign the new change request to an edition unless you want to create edition-dependent hierarchies in the change request. The corresponding change request type does not have to reference an edition type in this case.

      With this validity concept, the edition field is not included in the database tables.

  • You use storage/use type to specify whether and how master data can be changed in Master Data Governance. The storage and use type also indicates which database tables are generated by the system:

    • 1 - Changeable via Change Request; Generated Database Tables

      The master data of this storage and use type can be changed in Master Data Governance with a change request. The system generates all necessary database tables: check and text tables as well as additional tables, for example, for attachments and sets.

      The common key fields of these tables are:

      • The entity type itself

      • The edition – if you previously specified in the data model that the validity of master data changes is restricted to editions

      • The entity types that are assigned to the entity type through leading relationships

      Furthermore, all tables contain a checkbox that indicates whether the master data record is active. If the entity is stored in the MDG active area, this checkbox separates data in the staging from active data. If the entity is stored in a re-use area, this checkbox is used to mark a copy of the data from the active area as a snapshot at the time when the change request was created. This snapshot is used during activation of the data to detect conflicting changes that were done directly to the active area.

      The settings you make for the entity type (such as language dependency) result in additional key fields in the text table and the tables for attachments and sets.

      The non-key fields contained in the text table are the entity texts. The non-key fields contained in the check table are the attributes of the entity type. The attachment and set tables contain predefined non-key fields. Furthermore, all database tables contain a checkbox that indicates the deletion of the master data record. For entities that are edition-based, this checkbox indicates the end of validity in time. For entities that are stored in a re-use active area, this checkbox is considered during activation to check if data needs to be deleted. The check table also contains attributes that record which user created or changed the data records and when this was done.

    • 2 - Changeable w/o Change Request; Generated Check/Text Tables

      The master data of this storage and use type can be changed in Master Data Governance without a change request. The system generates only the check and text tables with the entity type as well as with the entity types assigned to the entity type through leading relationships as fixed key fields.

      The non-key fields contained in the text table are the entity texts. The check table does not contain non-key fields.

    • 3 - Not Changeable via MDG; No Generated Tables

      The master data of this storage and use type cannot be changed in Master Data Governance. Therefore, the system does not generate database tables. Instead, the system derives the available values from the domain that is assigned to the data element – either from the assigned value table or from the domain fixed values. Entity types with this storage and use type are typically used as reference values in qualifying relationships.

    • 4 - Changeable via Other Entity Type; Generated Database Tables

      The master data of this storage and use type can be changed in Master Data Governance only with a change request of an entity type with storage and use type 1. The entity type needs to be in a relationship with the relationship type leading and assigned as the To-entity type to an entity type with storage and use type 1. The system generates the check table as described for storage and use type 1, but also generates the entity types that are assigned through qualifying relationships as key fields. The system does not generate a text table, attachments, or sets since entity texts are not allowed for entity types with this storage and use type.

    The constraints described in the “Relationships” section apply when you assign a storage and use type to an entity type.

  • If you want to model the hierarchy arrangement of entities with specific entity types during master data processing, you can allow a hierarchy structure for each entity type. By doing this, you define whether these hierarchies are version-dependent or cross-name, or whether a combination of these attributes is to apply to the hierarchies.

    • If you create version-dependent hierarchies, you can define different hierarchy versions in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Process Modeling Next navigation step Create Hierarchy Versions End of the navigation path.

    • In cross-name hierarchies, the structure of the substructures – that is, the entities with their lower-level entities – is identical in all hierarchies.

    You also define in the data model which entity type is to be used as an end node (without lower-level nodes) in the hierarchy, which entity type is to be used as the root node (hierarchy name) of the hierarchy, and which additional entity types are permitted for the hierarchy. By default, a hierarchy can contain one root node and multiple entities of the hierarchy-defining entity type. You can also assign other entity types with storage and use types 1, 2, and 3 to the hierarchy.

    Note Note

    Entities of the entity type that you define as the root node cannot be used as lower-level entities in the hierarchy. No relationships with relationship type Leading can be defined for the entity type itself.

    End of the note.

    You can also specify in the data model whether the system is to restrict the validity of the hierarchy for an entity type to editions.

    The system automatically generates the database tables needed to store the hierarchies. They contain the following key fields:

    • The edition – if you previously specified in the data model that the validity of the hierarchy for this entity type is restricted to editions

    • A checkbox that indicates whether the master data record is active

    • The higher-level entity type

    • The higher-level entity

    • The lower-level entity type

    • The lower-level entity

    • The hierarchy version (if the hierarchy is version-dependent)

    • The hierarchy name (that is, the entity of the entity type you defined for the root node) if the hierarchy is not cross-name

    The table also contains a checkbox (as a non-key field) that indicates whether the respective master data record has been deleted, as well as a sequence number. This number specifies the sequence of the respective lower-level entities.

  • To define the technical properties of an entity type or the texts for field labels and input help on the user interface for Master Data Governance, you can assign an existing data element to the entity types with storage and use type 1. You must assign a data element to entity types with storage and use types 2 and 3. This assignment is not permitted for entity types with storage and use type 4.

    Note Note

    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.

    End of the note.
  • By assigning the 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 the system. You can also define whether processors are permitted to later change these keys.

    Note Note

    If you select a setting other than Key Cannot Be Changed; No Internal Key Assignment as the type of key assignment, the generated database tables change as follows:

    • Check table

      The table key contains a technical field instead of the entity type and its higher-level entity types. The entity type and its higher-level entity types are included in the attribute area of the database table.

    • Hierarchy table

      The hierarchy table does not change.

    • Other tables

      The key for the tables contains a technical field instead of the entity type and its higher-level entity types.

      The system generates a mapping table. The database table key contains a technical field for the mapping table. The attribute area contains the entity type and its higher-level entity types. If you select the Key Can Be Changed; Internal Key Assignment Possible setting as the type of key assignment, an additional attribute field to store the temporary key is added to the mapping table.

    • If the entity type is used as a From-entity type in relationships (see the “Relationships” section), the technical field replaces the entity type and its higher-level entity types in the corresponding tables.

    End of the note.

    You also need to assign a number range object in this data model that the system can use to derive the required temporary keys when keys are assigned internally (before the entity is activated).

  • If you want to define texts for an entity type, you can specify the length of the short, medium, and long texts and you can specify whether these texts are to be stored as language-dependent in the database tables.

  • You can enter a more detailed description of the objects in the data model (entity type, attribute, or relationship). For entity types without data elements, the system also uses this description for display in master data maintenance.

  • For entity types with storage and use type 3 whose data elements reference a check table that, in turn, does not reference a text table, you can specify texts for the source field (short text, medium text, and long text). The system uses the text that can be stored in this check table field as the descriptive text of the entity type’s attributes (for example, when formatting the input help).

  • You can specify whether deletion of entity types by means of change requests is permitted.

Relationships

To map the structure of your master data management in the data model, you define relationships between the individual entity types. The relationship type determines whether one entity type (From-entity type) is at a higher level than another entity type (To-entity type) or whether it is to be copied as an attribute of the other entity type in the check table:

  • Relationship type Leading (P)

    In this relationship type, the From-entity type is at a higher level than the To-entity type. This means the From-entity type is added as a key field to the database tables of the To-entity type, along with all assigned entity types with storage and use type 4.

    The From-entity type from a leading relationship to an entity type with storage and use type 4 is the respective entity type with which you can process the master data of the To-entity type with a change request.

    You cannot specify a data element.

    The cardinality 1:N is only permitted for this relationship type when no data element is specified.

    The cardinality 1:0 is also permitted if:

    • The To-entity type has storage and use type 1, no data element, and no additional relationships with the relationship type Leading.

    • The To-entity type has storage and use type 4 and no additional relationships with the relationship type Qualifying.

  • Relationship type Qualifying (Q)

    This relationship type is only relevant for From-entity types with storage and use type 4. It is used to define additional key fields in the database tables. For entity types of this storage and use type, the system – by default – transfers only the key fields of the From-entity type from the leading relationship.

    Only the cardinality 1:N is permitted for this relationship type. You cannot specify a data element.

  • Relationship type Referencing (-)

    This relationship type declares that the From-entity type is to be used as an attribute of the To-entity type. The description (name) of this type of relationship is inserted as a non-key field in the check table of the To-entity type.

    The cardinalities 1:N and 0:N are permitted for this relationship type. A data element can be specified in this case. However, this data element must have the same technical properties as the data element assigned to the From-entity type.

    As an alternative to a referencing relationship with a From-entity type with storage and use type 3, you can also define the attributes for the corresponding To-entity type directly. You configure this setting in Customizing for Master Data Governance under Start of the navigation path General Settings Next navigation step Data Modeling Next navigation step Edit Data Model End of the navigation path in the subdialog Attributes.

    Note Note

    Whether you use a relationship with the relationship type Referencing to define attributes or whether you define these directly (where possible) depends on the settings configured in the data model and on the use type of the attributes. For example, if an attribute is a value to which a unit or currency is to be assigned, you must define this directly. In contrast, if an entity type with storage and use type 3 that you can use for attribute definition already exists, you should define a referencing relationship.

    End of the note.

Which relationship types are permitted depends on the storage and use types of the entity types:

Example Example

For an example of the database tables the system generates for entity types with different properties defined in the data model, see Example: Generated Database Tables.

End of the example.