mdm400

MDM400Data Modeling

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 92Course Duration: 3 Day(s)Material Number: 50096771

An SAP course - use it to learn, reference it for work

Copyright

Copyright © 2009 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP AG. The information contained herein may be changedwithout prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Trademarks

• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® areregistered trademarks of Microsoft Corporation.

• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

• ORACLE® is a registered trademark of ORACLE Corporation.• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered

trademarks of Informix Software Incorporated.• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.• Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarksof Citrix Systems, Inc.

• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, WorldWide Web Consortium, Massachusetts Institute of Technology.

• JAVA® is a registered trademark of Sun Microsystems, Inc.• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for

technology invented and implemented by Netscape.• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP

EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.comare trademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Disclaimer

THESEMATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLYDISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDINGWITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR APARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTSCONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANYKIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOSTPROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDEDSOFTWARE COMPONENTS.

g2009101811120

About This HandbookThis handbook is intended to complement the instructor-led presentation of thiscourse, and serve as a source of reference. It is not suitable for self-study.

Typographic ConventionsAmerican English is the standard used in this handbook. The followingtypographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as wellas menu names, paths, and options.

Also used for cross-references to other documentationboth internal and external.

Example text Emphasized words or phrases in body text, titles ofgraphics, and tables

EXAMPLE TEXT Names of elements in the system. These includereport names, program names, transaction codes, tablenames, and individual key words of a programminglanguage, when surrounded by body text, for exampleSELECT and INCLUDE.

Example text Screen output. This includes file and directory namesand their paths, messages, names of variables andparameters, and passages of the source text of aprogram.

Example text Exact user entry. These are words and characters thatyou enter in the system exactly as they appear in thedocumentation.

<Example text> Variable user entry. Pointed brackets indicate that youreplace these words and characters with appropriateentries.

2009 © 2009 SAP AG. All rights reserved. iii

About This Handbook MDM400

Icons in Body TextThe following icons are used in this handbook.

Icon Meaning

For more information, tips, or background

Note or further explanation of previous point

Exception or caution

Procedures

Indicates that the item is displayed in the instructor'spresentation.

iv © 2009 SAP AG. All rights reserved. 2009

ContentsCourse Overview ......................................................... vii

Course Goals .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiCourse Objectives ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vii

Unit 1: General Introduction into Data Modeling ................... 1Why Do We Need Data Modeling? ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2What is Master Data and what is it not? .. . . . . . . . . . . . . . . . . . . . . . . . . . 11

Unit 2: MDM Data Modeling Basics .................................. 21MDM Table Types and Properties .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22MDM Field Types & Properties.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Unit 3: MDM Data Modeling Practice ................................ 71MDM Data Modeling Procedure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72MDM Data Modeling Best Practices... . . . . . . . . . . . . . . . . . . . . . . . . . . . .108MDM Data Modeling Issues and Solutions ... . . . . . . . . . . . . . . . . . . . .130

Unit 4: MDM Data Modeling Implementation Approach........ 137MDM Data Modeling Implementation Approach Case Study ..138

2009 © 2009 SAP AG. All rights reserved. v

Contents MDM400

vi © 2009 SAP AG. All rights reserved. 2009

Course OverviewThe effectiveness of a MDM repository is dependent upon the proper datamodeling of its tables and fields. Too often traditional data modeling techniquesare applied to repositories which yield less than desirable results. The results fromnot taking into account the rich collection of tables, fields and their respectiveproperties available in MDM. MDM is far more than a mere database, but offersrich functions for the management of data and the establishment of and continuingmaintenance of high levels of data quality.

Target AudienceThis course is intended for the following audiences:

• Project team member and Solution Consultants needing knowledge ofprinciples of Data Modeling and Data Quality in Master Data Management

Course PrerequisitesRequired Knowledge

• MDM050 Master Data Management Overview• MDM100 Master Data Management Configuration

Course GoalsThis course will prepare you to:

• Attain knowledge of the principles of data modeling and data quality as itpertains to MDM

Course ObjectivesAfter completing this course, you will be able to:

• Describe the principles of data modeling and data quality pertaining to MDM• Demonstrate the application of the principles of data modeling and data

quality to MDM repositories

2009 © 2009 SAP AG. All rights reserved. vii

Course Overview MDM400

viii © 2009 SAP AG. All rights reserved. 2009

Unit 1General Introduction into Data

Modeling

Unit OverviewA company would like to maintain customer data and their relationships toaccounts. Each customer can have one or several accounts. Customers can belongto other customers (subsidiaries). The company would like to know what needs tobe considered when modeling their data models and what MDM-specific tweakscan be used.

Unit ObjectivesAfter completing this unit, you will be able to:

• Explain why data modeling is important• Determine the relevant data for a data model• Explain the consequences of a wrong data model

Unit ContentsLesson: Why Do We Need Data Modeling?... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Lesson: What is Master Data and what is it not? .. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2009 © 2009 SAP AG. All rights reserved. 1

Unit 1: General Introduction into Data Modeling MDM400

Lesson: Why Do We Need Data Modeling?

Lesson OverviewThis lesson

Lesson ObjectivesAfter completing this lesson, you will be able to:

• Explain why data modeling is important

Business ExampleYour company plans to use SAP NetWeaver MDM. Several SAP and legacysystems should be connected to MDM. The pre-delivered Standard repositoriescannot be used, so it is necessary to define a new data model, which fits to yourbusiness requirements.

Data ModelingMaster data is a critical company asset that flows through every department of acorporation. Optimal business decisions are dependent on the quality and accuracyof master data. Master data that is inconsistently stored in multiple, disconnectedsystems or databases may be inaccurate, redundant, and full of discrepancies, allof which result in high maintenance costs, vulnerable business processes andpoor business decisions.

The goal of master data management is to provide first-class master data forsustained cross-system data consistency. The master data quality function includesa whole array of features to ensure quality standards for master data in thefollowing categories:

• Accuracy - Does my data adhere to defined formats and standards?• Completeness - Does my data contain all the necessary information?• Validity - Does my data contain incorrect information?• Consistency - Does my data contain contradicting or duplicate information?

SAP NetWeaver MDM offers a number of functions for ensuring and improvingdata quality.

Master data quality begins with the data model. It is important to have a clearunderstanding of the data that will be included in the model, as well as, anyrelationships with data from external sources.


MDM400 Lesson: Why Do We Need Data Modeling?

Figure 1: Data Modeling Is Like:

Let us suppose that we have two areas of interest that we wish to analyze:Customer and Account

Again we are looking for one fact in one place.

As in a file cabinet it, is key to access master data quickly without a complicatedsearch. By going to one specific place you would be able to access the rightinformation.

If your file cabinet is badly organized it takes you too long to find the rightinformation. The same can be said for MDM. A wrong data model can causeperformance problems when searching or processing master data.

Figure 2: Each Customer Card

Each customer card will have a field for each of our data elements we want tokeep about Customer.



Figure 3: Each Account Card

Each account card will have a field for each of our data elements we want tokeep about an Account.

So what will the data actually look like?

Figure 4: Sample Customer Cards

We now have some customer data population.

We added a customer ID – to have something unique so later on we can easily findthe exact customer card we are looking for next time. The customer names maybe the same so they cannot be used in a perfect way.



A solution is to just use a number and the next customer will just get the nextnumber.

Figure 5: Sample Account Cards

The account numbers look like they are unique so we can use those to identifyeach account card.

Here the first question pops up on how to structure the data. Do we want to haveone cabinet or two separate cabinets? In case of two cabinets, the cabinets needto have some overlaying functionality, pulling the right cards from both cabinetstogether.

But something is missing in this picture.

Figure 6: Customer and Account–How many repositories?



What if we want to know which accounts belonged to ABC Incorporated?

What if we need to know the net worth of the customer that owns accountP123456?

With our current structures in place we do not have this information. If we havetwo repositories, we lack a cross reference.

If we only want one repository with a single Main table, then the Main table willconcentrate on the cross rererence.

Figure 7: Each Ownership Card

So we need a file drawer that allows us to link the customer to the accounts thecustomer owns. The structure of such a file drawer looks pretty simple. Theownership between customer and account consists simply of these two fields.

That will do it. Now let us see what our data might look like.

Figure 8: Sample Ownership

Now we are able to find all the accounts for a customer.



Figure 9: Customer and Account as Two Main Tables–Single Repository

It is also possible to find the customer that owns a particular account.

If we want a single repository with more than one Main table, then we can housedate for each object, Customer and Account, and each Main table can refer tothe other.

Figure 10: Some Customers Belong to Others

Sometimes it is also possible that customers belong to other customers, whichmeans a customer is, for example, a subsidiary of an overall global customer.



In MDM notation such a relationship can be defined using MDM specific tabletypes, for example, relationships or Hierarchy tables. This allows us to store andmaintain relationship info between several customer objects

Figure 11: Different Customer Types Can Have Different Properties

When we are maintaining the data of our customer base, we will find out thatthere are many different kinds of customers, like on-time customer, individualcustomers, corporate customers, just to name a few.

By nature all of these different customer types have different properties tomaintain. Some of them are unique to certain customer types (e.g. Fiscal Year-Endfor Corporate customers but not for individual customers), others are generic andcan be maintained for each customer type, like a ZIP code.

Since MDM provides a special feature (taxonomy) to maintain informationespecially for certain customer types, it is worth to spend some time there to findout whether this can be utilized.

MDM Content

MDM Content delivered by SAP, is based on best business practices and isintended to be used as a model to begin development projects. MDM contentis specific for a master data object type: Customer, Material, Vendor, Supplier,Business Partner, Product, Employee. MDM content may be downloaded from theSAP Software Download Center (https://service.sap.com/swdc).

MDM Content consists of two parts.

The first one is content for the SAP NetWeaver MDM Server. This includesMDM related development objects (e.g. repositories, table and field definitions,workflows, Import and Syndication maps, Portal Content, and so on). The servercontent enables the storage and maintenance as well as import and export ofmaster data in MDM.



The second part is content for MDM connectivity. This includes all objects neededto connect the MDM server to its remote systems (e.g. PI Content, extractors forcustomizing and master data, and so on). The connectivity content enables theextraction and distribution of master data from and to remote systems, as well as,the related monitoring and supportability of the processes.



Lesson Summary

You should now be able to:• Explain why data modeling is important


MDM400 Lesson: What is Master Data and what is it not?

Lesson: What is Master Data and what is it not?

Lesson OverviewThis lesson explores the definition of master data. Unless the nature of masterdata is recognized, it is possible to attempt to model certain classes of data in amaster data management repository. Afterwards the error will be discovered whenattempting to import data into and syndicate data from the repository.


• Determine the relevant data for a data model• Explain the consequences of a wrong data model

Business ExampleA company would like to maintain their products by using a master datamanagement solution. There is an uncertainty on which kind of data is reallymaster data and what is not. Different people have different opinions about it.

Definition of Master DataWhat is Master Data?

• Master data serves as the fundamental building block of all information in asystem and is essential to running business processes.

• A key element in providing critical business reports.• Master data examples include: Customers, Vendors, and Materials

Figure 12: Definition of Master Data

Master data is the information used to describe objects or entities that are part of acompany. These are objects that a company needs to perform its mission.

Master data records are usually shared across the enterprise, but this is not arequirement.



Figure 13: Managing Data as a Means to Information

Let us put master data in perspective. This pyramid shows the hierarchy of datanecessary to get to a reporting level. This is also a good illustration of howimportant it is to get master data right.



It is important that to consider each type of data and how each type is affectedby the others:

• Reporting Data

Includes summary reports and metrics (KPIs).

• Transactional Data

Actions or activities that are logged and referenced in processes, such as apurchase order or an accounting journal entry.

• Conditional Master Data

Similar to master data, but typically changes more often. Conditional masterdata is linked to master data through rules or conditions. Examples areproduct pricing or material info records related to material master records.

Sometimes this data is relatively stable, e.g. product price. While at othertimes it is more volatile, e.g. price paid at the time of purchase.

• Master Data

Master data is the information used to describe objects or entities that are anessential part of a company. Examples of master records include products,suppliers, materials, vendors, employees and business partners.

• Key Reference Data

Includes simple dropdown lists and industry standard data. Examples areunits of measure, company codes, valid value for employee group, UNSPSCcodes, etc.

Another type of data to consider is Metadata, which includes business rules,attribute and data definitions. Metadata is the backbone providing the structurebehind all of the other types of data.

Examples of master records include products, suppliers, materials, vendors,employees and business partners.



Figure 14: Master and Transactional Data Interact Together

A transaction is a recorded event based on an intersection of master data objects.For example, a purchase order requires materials from the Material Master, abuyer from the Customer Master, and a manufacturer from the Vendor master.

We need to ask the question, “Is Everything Master Data?”

Figure 15: Is Everything Master Data?

Master data is relatively static. After you create it, there are few, infrequentchanges needed. Changes are typically made in a controlled manner, e.g. acustomer changes their address of phone number.

Master data is structured with specifications for the specific attributes to describethe master data object and rules to describe what is entered in each attribute. Ifthere are no rules, then the attribute may not be necessary.

Master data is not a record of an action or an activity. A record of an action or anactivity is a transaction.

Master data does not typically change continually based on business rules or thebusiness environment.



Figure 16: Are Text Fields Master Data?

Text fields used for descriptions or even as object identifications should be partof a master data management repository. Descriptions give master data a moreuser-friendly approach.

Figure 17: Are Indicators Master Data?

Actually it depends on the indicator. The above is an illustration of an indicatorwhich is based on an analysis of event (transaction) data. This kind of indicatorcan change with a frequency dependent upon the frequency of the analysis. Otherindicators, such as “MRP Type.” or “Billing Relevance” might be necessary todescribe the master data object and aid in the syndication of this data to a remotesystem. The configuration or definition or implications of the indicator settingare certainly not part of master data, but can be shown and even maintained ina repository.

Figure 18: Are Stock Levels Master Data?



Stock levels, such as “stock on hand” are values which are entirely dependent ontransactional events which are classes as either “inflow” quantities from purchaseor production orders and “outflow” such as sales orders or deliveries. Certaintypes of stock levels, such as “buffer stock,” which indicates how much of aquantity of material needs to be kept in reserve at all times, is determined only onindividual materials and thus, are not dependent on transactions. The term bufferstock could almost be considered an indicator.

Figure 19: Are GTIN Numbers Master data?

GTIN numbers form a critical piece of information of products when usingproducts with trading partners. While the determination (definition) of GTIN's aretoo involved for repository determination, the inclusion of GTIN's in a productrepository will facilitate remote system processing after syndication of thisinformation to the remote system.

Figure 20: Is Pricing Master Data?



Pricing is often a confusing piece of information unless one remembers that thereare different concepts of pricing. First there is the “price a customer pays for anitem upon purchase.” Every new automobile on a car dealer's lot has a stickerreflecting the MSRP (Manufacturers Suggested Retail Price). People shopping fora new car do not want to pay the MSRP, but depending on circumstances and//ornegotiation skills will pay a percentage less than the MSRP.

In terms of SAP ECC, material pricing is based on the concept that each materialhas a “Base Price” to which discounts, surcharges and taxes are added to arrive ata price which a customer will pay upon purchase. The “Base Price” is dependentonly on the material involved and not on an event (sales order).



Lesson Summary

You should now be able to:• Determine the relevant data for a data model• Explain the consequences of a wrong data model


MDM400 Unit Summary

Unit SummaryYou should now be able to:• Explain why data modeling is important• Determine the relevant data for a data model• Explain the consequences of a wrong data model


Unit Summary MDM400


Unit 2MDM Data Modeling Basics

Unit OverviewYour company decided to implement SAP NetWeaver MDM. You are to explainthe basic fields and ables and their properties in MDM.


• Describe the different table types in MDM.• Explain how the different types of tables are used in MDM.• Describe the properties assigned to MDM tables.• Explain how the different table properties are used in MDM.• Explain the different field types in MDM.• Explain the different field properties in MDM.

Unit ContentsLesson: MDM Table Types and Properties .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Lesson: MDM Field Types & Properties .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Exercise 1: MDM Field Types & Field Properties .. . . . . . . . . . . . . . . . . . . . . . 55Exercise 2: Add fields to delivered Material Master Repository .. . . . . . 59


Unit 2: MDM Data Modeling Basics MDM400

Lesson: MDM Table Types and Properties

Lesson OverviewThis lesson provides a review of the different table types and table propertiesthat are supported in MDM.


• Describe the different table types in MDM.• Explain how the different types of tables are used in MDM.• Describe the properties assigned to MDM tables.• Explain how the different table properties are used in MDM.

Business ExampleYour company decided to implement SAP NetWeaver MDM. You are to explainthe basic fields and tables and their properties in MDM.

MDM Table TypesMDM is an integrated system for master data management. MDM runs on astandard SQL-based relational database management system, but MDM is muchmore than a simple database application. Many of the standard database functionsare extended and optimized in MDM. Standard relational database structures donot support the advanced model required for master data management.

MDM features a SQL-based database structure that is extended and optimizedfor master data management. MDM delivers powerful tools both for managinginformation and for classifying it into a hierarchy of categories and subcategories.

MDM layers a thick shell of functionality on top of a powerful SQL-based DBMSso that the MDM system is fully scalable and the master data is fully accessible toother SQLbased applications and tools.

An MDM repository includes a database of information consisting of text, images,PDFs, and other data about each master record.

The MDM repository supports the complexity of the underlying information, aswell as, the means to search, maintain, import and distribute the master data.MDM also supports a robust master data cataloging functionality that deliversboth web-based and print catalogs.

The MDM system supports a variety of different table types that are specificallysuited for storing, organizing, structuring, classifying, managing, and publishingproduct information in a product repository, including efficient support forcategory-specific product attributes that are inherently non-relational.


MDM400 Lesson: MDM Table Types and Properties

An MDM repository consists of the following types of tables:

• Main tables• Sub-tables• Object tables• Special tables

Figure 21: MDM Console: Repository Structure

Main Table: Every MDM repository has at least one main table. The main tableconsists of object information. It includes an individual record for each object inthe repository and an individual field for each piece of object information thatapplies to all of the records, such as SKU, product name, product description,manufacturer, and price for the object product. Most of the time, you will belooking at information in the main table.

A main table is a flat table that has the standard, rectangular SQL structureconsisting of records and fields (rows and columns). The main table of an MDMrepository is always a flat table.

As of MDM 7.1, one repository may contain multiple main tables. For example,Products and Suppliers may reside in the same repository.



Figure 22: MDM Multiple Main Tables 1

This capability offers benefits that contribute to the strength and flexibility ofthe MDM model. The main tables may share common look-up tables, as wellas, cross-reference each other.

Figure 23: MDM Multiple Main Tables 2



Figure 24: Lookup Main Table

An SAP MDM repository can have any number of sub-tables. A sub-tableis usually used as a lookup table to define the set of legal values to which acorresponding lookup field in the main table can be assigned; these tables holdthe lookup information.

For example, the main table may include a field called Manufacturer; the actuallist of allowed manufacturer names would be contained in a sub-table. Only valuesthat exist in sub-table records can be assigned to the value of the correspondinglookup field in the main table.

Note: SAP recommends using the singular for lookup field names,“Manufacturer”, and the plural for table names, “Manufacturers”.

Sub-tables: Flat Tables and Qualified Lookup Tables

A flat table is always a sub-table. It has the standard, rectangular SQL structureconsisting of records and fields (rows and columns).

Direct support refers to the flat lookup or qualified lookup tables that arereferenced by the fields in the main table.



Indirect support refers to the tables that are linked to qualifier table, but thequalifier table is linked to the main table.

Hint: Data Integrity:

Lookup sub-tables are just one of the powerful ways that MDM enforcesdata integrity in an MDM repository.

Figure 25: Flat and Qualified Lookup Table

The set of legal values associated with lookup fields also makes the MDMrepository much more searchable, since a consistent set of values is usedacross the entire repository.

A qualified table in MDM stores a set of lookup records and also supportsqualifiers, or sub-fields, that apply not to the qualified table record by itself, butrather to each association of a qualified table record with a main table record.MDM supports multiple simultaneous qualified tables.

Qualified tables can be used to support product applications and application-basedsearch, and also to store any large set of sub-table records that contains fieldswhose values are different for each main table record, such as multiple prices fordifferent quantities, divisions, regions, or trading partners; cross-reference partnumbers; and additional distributor/supplier/customer-specific information fordifferent distributors, suppliers, or customers.

All lookup tables in an SAP MDM repository are sub-tables, but not all sub-tablesare used as lookup tables. There are a number of subtle differences among thedifferent types of lookup tables.

MDM Tuples



With MDM 7.1, the Tuple, was introduced. Tuples define custom composite datatypes consisting of a set of multiple fields.

Figure 26: Tuples

Tuples are a basic, all-purpose data modeling building block that have manyuses and capabilities for structuring and storing MDM data. Tuples that includelookups extend and generalize other specialized MDM structures, such as qualifiedlookup tables and parent/child relationships.



Features and benefits of MDM tuples include:

• Custom types. Defines custom composite data type consisting of a set ofmultiple fields (a “tuple”)

• Grouping. Groups related fields together into a reusable object; like a tabledefinition (but without an instance of the table).

• Reusability. Unlike a table definition, the named set of fields can be definedonce and reused many times in multiple places.

• Properties. Can attach validations, security provisions and other propertiesto the tuple definition.

• Encapsulation. Any change to the tuple structure or to its associatedproperties is immediately propagated to every usage.

• Composite anything. Complements existing composite types (e.g.Measurement and Coupled Numeric) with a custom composite type.

• Qualified lookups. Can be used to create a fully qualified reference from therecords of one table to the records of any other table type.

• Parent/child relationships. Can be used to model parent/child relationshipswith full support for relationship qualifiers.

• Hierarchy management. Can be used to model arbitrarily complexhierarchical main entity relationships, including support for qualifiers.

• XML compatible. Provides a natural way of representing an XML schemadefinition and storing the corresponding XML data.

• Referential clarity. Appears as a field in the parent record, exposing theparent/child association between records in multiple tables.

• Nested structures. Stores nested private subrecords that are owned by and donot exist outside of the parent record (i.e. “containment”).

• Deep nesting. Can include a reference to another tuple for arbitrarily deepmulti-level nesting (e.g. Plant > Address > Contact > Phone).

• One-to-many relationships. Tuple reference can be multi-valued (e.g.multiple addresses > multiple contacts > multiple phones).

The most notable feature of tuples is that they allow you to create nestedstructures, including deeply nested multi-level structures of arbitrary depth, with aone-to-many relationship



Figure 27: Tuples 1

Tuples:

• support deeply nested multilevel structures, for example, Address, Contact,Phone.

• can be used to model arbitrarily complex hierarchical main entityrelationships.

• can be used to create qualified references to the records of any other table.



Figure 28: Tuples 2

The following graphic depicts a deeply nested structure using Tuples.



Figure 29: Tuples: An Example of Deep Nesting Using Tuples

Hint: Nested structures, hierarchy management, and extended qualifiersupport are not explicit metamodel enhancements but rather beneficial“side effects” of combining Lookup [Main] and tuple fields in variousways. Tuples add flexibility and efficiency to the MDM model.

Sub-tables: Hierarchy and Taxonomy Tables

A hierarchy table organizes information in a hierarchy, where each record isrelated to a parent record (even if the only parent is the root) and may also berelated to sibling records and/or child records. The main table in an MDMrepository typically contains some fields whose data may be hierarchical innature. For example, a Manufacturer field may need to accommodate divisionand subdivision information for manufacturers. This hierarchical information isstored in a separate, hierarchy sub-table associated with the Manufacturer lookupfield in the main table.

Most of the hierarchy tables used in an MDM repository contain lookupinformation for fields in the main table. Other hierarchy tables in MDM includetaxonomy tables, the Masks table, and the Families table. MDM supportshierarchies with an unlimited number of parent/child levels.



Figure 30: Hierarchy and Taxonomy Tables

Hint: A flat hierarchy table (only leaf nodes below the root) can be usedto flexibly store sibling records in any sort order. For example, recordsof a table sorted alphabetically can be sorted in any order when a flathierarchy table is implemented.

A taxonomy is the classification scheme that defines the categories andsubcategories that apply to a collection of records. Categorizing records enablesyou to isolate subsets of records for various organizing, searching, editing andpublishing purposes. A taxonomy table in MDM stores a hierarchy of categoriesand subcategories and also supports attributes, which are sub-fields that apply toparticular categories rather than to the entire collection of records. MDM supportsmultiple simultaneous taxonomies.



Figure 31: SAP MDM Repository Categorization 1

A taxonomy table is a special kind of lookup table. It provides support for ahierarchy of category and subcategory records.


The hierarchy of product categories and their associated category-specificattributes are created and managed using the SAP MDM Data Manager inTaxonomy mode. By convention SAP MDM often refers to this table as theCategories table. Every product should belong to a category.



Categorizing products enables you to isolate subsets of products for variousorganizing, searching, editing and publishing purposes. A taxonomy table inSAP MDM stores a hierarchy of categories and subcategories and also supportsproduct attributes, database “subfields” that apply to particular product categoriesrather than to the entire collection of products. SAP MDM supports multiplesimultaneous taxonomies.

It provides support for category-specific attributes that can be assigned to eachcategory on a category-by-category basis.

The taxonomy table itself and the fields of each of its records are created anddefined in the SAP MDM Console.


Attributes:

• Every taxonomy table has a pool of attributes associated with it. Fromthis pool you can link attributes to one or more individual categories on acategory-by-category basis. SAP MDM allows you to manage the pool ofattributes associated with a taxonomy table in Taxonomy mode.

• In SAP MDM, attributes are associated with categories.

Note: In SAP MDM, an attribute is like a field, but one that applies onlyto a subset of the records in a table. By contrast, a field is part of everyrecord in a table. If a particular attribute can be applied to every productin a repository, then it should be set up as a field in the main table. Forexample, every product in a repository probably has an item number;therefore “Item Number” should be defined in the database as a field,and not as an attribute.



Figure 36: SAP MDM Repository Objects 1: Flat versus Hierarchy Tables

All lookup tables in an SAP MDM repository are sub-tables, but not all sub-tablesare used as lookup tables. There are a number of subtle differences among thedifferent types of lookup tables.

Note: A product can belong to at most one leaf-node category.

SAP MDM can support multiple simultaneous taxonomies within a singlerepository. For example, multiple taxonomies in a repository may be used forproduct groupings or for web searches.

Qualified Tables



Figure 37: SAP MDM Repository Qualified Tables 1

Unlike the number of qualified table records, the number of qualified link tablerecords (where each record corresponds to a main table record or qualified tablerecord link) is typically much larger than the number of main table records, andthe relationship between qualified table records and qualified link table records isone-to-many.

The use of qualifiers creates a two-level relationship (from main table to qualifiedtable to qualified link table) that eliminates data duplication and dramaticallyreduces the number of qualified table records, making the qualified table morememory efficient and usable as a searchable lookup table.



Figure 38: SAP MDM Repository Qualified Tables 2

Special tables

Special tables include the Image Variants, Masks, Families, Relationships,Workflows, Named Searches, Tuples, Data Groups, and Validation Groups tables.Each special table has its own particular behavior with respect to how it is createdand how it is managed.

When a new MDM repository is created, MDM automatically creates the singleinstance of each special table. The Data Groups and Validation Groups tables donot appear anywhere in MDM Console.

Special table: Families Table

The Families table is a special table that contains family records. Like the normaltables, family records consist of fields specified within MDM Console; however,the records themselves are created and maintained automatically by MDM basedon the specifications provided for the Family Hierarchy in the MDM Client inFamily mode.

Each family corresponds to a single record in the Family Hierarchy. In addition tostoring family data for the family in each of the fields you specify for the table,each leaf node family record stores the set of like main table product records thatare members of the family. The family structure allows you to associate family dataonce with the family rather than with each individual product within the family.

The Field Detail pane for the Families table includes an additional property for theFamily Field. This is the main table lookup field that will be used as the primarypartition of main table records into families.



In a traditional Family Hierarchy, the Family Field is usually a taxonomy lookupfield, although you can use any hierarchical lookup field.

When a new MDM repository is created, MDM automatically: (1) creates theFamilies table; and (2) sets the Family Field to the Category taxonomy lookupfield of the main table.

To add the Families table manually, there must be a taxonomy lookup field in themain table that can be used as the Family Field (typically the Category field). Onlyobject lookup fields are valid Families table fields.

Figure 39: Families and Relationships

Special table: Relationships Table

The Relationships table is a special table with a predefined set of fields, andrecords that appear in the top-right Relationships pane of MDM Console. Eachrecord that added in MDM Console defines a particular product-level relationship,chosen from among several different basic structural relationship types.

When a new MDM repository is created, MDM automatically creates theRelationships table.

A relationship defines the type of relationship but does not specify any of therecords that participate in that relationship. For each relationship defined in MDMConsole, the related products and/or non-products for each record are specified inMDM Data Manager.

Product relationships may be added, modified, and deleted just like the fields ofa normal MDM table.



Figure 40: Relationships Assignment in Data Manager

In practice, an SAP MDM repository can often represent the same sub-tableinformation using either a qualified table or a parent/child product relationship,each with slightly different effect; choosing the right structure depends on howyou intend to search the Repository.

For example, if:

• (1) the sub-table records have one or more lookups fields,• (2) a portion of the sub-table records consists of values that are shared by the

main table records while another portion consists of values that are differentfor each main table or sub-table record link,

• (3) You want SAP MDM to limit main table product records using drill-downsearch against the sub-table records,

• then use a qualified table (which reduces the number of sub-table recordsthrough the use of qualifiers).Alternatively, if the number of sub-table records is very large (larger than thenumber of main table records), and full validation against all of the sub-tablerecord values is important, then use a parent/child product relationship.



Figure 41: Relationships - Parent/Child or Sibling?

Object tables: Object tables include the images, text blocks, and PDFs tables. Anobject table is a special type of lookup sub-table, where each object table is usedto store a single type of object, such as images, text blocks, or PDF files.

Objects are not stored directly in a main or sub-table field in an SAP MDMrepository. Instead, each object is defined or imported into the repository once andthen linked to a main or sub-table field as a lookup into the object table of that type.

Object tables eliminate redundant information, since each object appears onlyonce in the MDM repository even if it is linked to multiple records.

The following table summarizes the differences in capabilities between Tuples,Qualified Tables, Relationships and Hierarchies.



Figure 42: Capabilities of Table and Structure Types

MDM Table PropertiesTable properties are set from the selected node in the Console Hierarchy tree ofan MDM repository. The objects pane (top-right) is titled Tables and the detailpane (bottom-right) is titled Table Detail. The Tables pane contains a grid with alist of tables in the MDM repository, where each table in the list corresponds to achild of the selected repository node.

Table type. Once a table is saved, its Type cannot be changed All the object tablesand all the special tables are added automatically when you first create a newMDM repository An MDM repository can have at most a single instance of eachobject, special, and system table type.

Display Field. The field whose value is used as: (1) the value of a lookup field;(2) the node name in hierarchy trees; and (3) the name of the record in the ProductRelationships popup window. The display field is not available for the objecttables or special tables.

Valid data types for Display Fields are AutoID, Integer, Real, Text, TextNormalized, Lookup [Flat], Lookup [Hierarchy], and Lookup [Taxonomy].

Unique Field. The fields that must contain unique values, or the fieldcombinations whose combined values must be unique. Not available for the objecttables or special table

Key Mapping:Use the Key Mapping table property to specify whether or notMDM should maintain key mappings for the records of a table.

Hide Table. Whether to hide the table from client applications (Yes/No)?Available on Masks, Named Searches, and user-created tables.



Figure 43: General Table - Technical Properties

A Unique Field for a table is a field that must contain a unique value for eachrecord, or in the case of a Unique Field combination, the field combinationswhose combined values must be unique for each record. For example, in the mainProducts table, SKU and UPC might each be a Unique Field, and the combinationof Manufacturer and Part Number might be a Unique Field combination.

Note: Object tables and special tables do not have Unique Fields.

Figure 44: Considerations Concerning Table/Field Properties



The uniqueness test is case-insensitive. For example, the values “ABC-123” and“abc-123” would be considered the same by MDM.

Even though a unique field generally prevents more than one record from havingthe same value (or value combination in the case of a unique field combination),multiple records are permitted to have the value NULL for the unique field. Thereason for this is that while unique fields are used to distinguish between multiplerecords, a unique field with the value NULL means the record has not yet beenfully defined, and therefore should not conflict with other records that are also notyet fully defined.



Lesson Summary

You should now be able to:• Describe the different table types in MDM.• Explain how the different types of tables are used in MDM.• Describe the properties assigned to MDM tables.• Explain how the different table properties are used in MDM.



Lesson: MDM Field Types & Properties

Lesson OverviewThis lesson provides a review of field types and properties.


• Explain the different field types in MDM.• Explain the different field properties in MDM.

Business ExampleYour company decided to implement SAP NetWeaver MDM. You were chosen toexplain the basic Fields and Tables and their properties in MDM.

MDM Field Types

Figure 45: MDM Field Types


MDM400 Lesson: MDM Field Types & Properties

A Display Field for a table is a field whose value is used as:

• The corresponding lookup field value for each record• The node name for the record in hierarchy trees• The name of the record in the Product Relationships dialog box.

When a table has multiple Display Fields, the value that is used for each recordis the value combination among the Display Fields with each pair of valuesseparated by a comma.

The Display Field can be changed, but a new field must be assigned a DisplayField before removing the previous fields Display Field property.

Figure 46: Field Details

A traditional SQL DBMS has a standard set of relatively simple data types (such astext, integer, and real) that allow you store a single element of unstructured data ineach field. Beyond knowing how to accept input of and properly store each type ofdata, SQL has no real understanding of the internal structure of each data element.



By contrast, an MDM repository supports a variety of compound and structureddata types which, like the set of MDM table types, are specifically suited formanaging information in a product repository.

Note: A Text Normalized field stores the actual text value, but uses thenormalized value for sorting and searching. The normalized value is anupper-case version of the original with non-alphanumeric charactersremoved (including a-z, A-Z, and 0-9).

Note: A regular Text field is faster than a Text Large field; only use a TextLarge field if you are certain that some values will require over 4000characters.

Figure 47: Field Properties

Most objects within an MDM repository (e.g. tables and fields) have a Codeproperty that is limited to the following characters:

• A-Z• a-z• 0-9• underscore

Required is only advisory and is used with validation expressions.

Even though a unique field generally prevents more than one record from havingthe same value (or value combination in the case of a unique field combination),multiple records are permitted to have the value NULL for the unique field. The



reason for this is that while unique fields are used to distinguish between multiplerecords, a unique field with the value NULL means the record has not yet beenfully defined and therefore should not conflict with other records that are also notyet fully defined.

Figure 48: Additional Field Properties for Dependencies and User Interface

Qualifiers allow a single lookup record to be used for multiple applications that arebasically the same except for the additional conditions, dramatically reducing thenumber of distinct applications in the qualified table and avoiding a tremendousamount of data duplication. Qualifier (Yes or No) is only applicable for qualifiedtables.

Qualifiers should almost always be cached (i.e. have their values stored inmemory) using the Cache field property for each qualifier field.

While this increases the MDM memory footprint somewhat, caching a qualifierhas several distinct advantages over not caching: (1) it dramatically improvessearch performance; (2) it permits keyword indexing to be set for the qualifier(using the Keyword field property) to support keyword search of qualifier data;(3) it permits drilldown search by qualifier lookup values even before you haveselected a single qualified table record in the qualified lookup field search tab; (4)it permits free-form search by qualifiers (both lookup and non-lookup) when SortIndex is enabled; and (5) it causes the set of qualified links for each record to befiltered based on the qualifier search value (both lookup and non-lookup).

Qualifiers should not be cached only if memory is limited, you do not need tosearch on its lookup values until you have already selected a qualified lookuprecord, and the number of qualified links is huge (e.g. more than 50 million).



Search Tab determines if the field should appear as a search tab for the table(Yes/No)? Default is: (1) Yes for lookup fields, lookup qualifiers, Booleanqualifiers, and tuples; and (2) No for Boolean fields.

Multi-valued fields (Yes or No) make the structure of an MDM repositorydramatically simpler, more compact, and more searchable, by allowing you tostore all the values corresponding to a particular data element in the same place.The alternative requires creating multiple fields or attributes, in some cases up to amaximum of one field or attribute for each possible value.

Figure 49: SAP MDM Console - Field Properties 1



Figure 50: SAP MDM Console - Field Properties 2

A Text Normalized field stores the actual text value, but uses the normalized valuefor sorting and searching. The normalized value is an upper-case version of theoriginal with non-alphanumeric characters removed (includes a-z, A-Z, and 0-9from original value).

In the tables above, a bullet in the column labeled “MV” means that the data typecan be defined as multi-valued, so that a single field or attribute can be used tostore multiple values.

In a taxonomy, every category has its own defining characteristics (in addition tothose of every category above it in the hierarchy). For example, in the taxonomyof animals, primates have specific characteristics as well as those of mammals andvertebrates. In an MDM repository, these characteristics are called attributes, andcorrespond to fields of information that apply only to some rather than all of themain table records in the MDM repository. For example, voltage might be anattribute that applies to motors but not to gears.

Every taxonomy table has a pool of attributes associated with it. Fromthis pool you can link attributes to one or more individual categories on acategory-by-category basis. MDM allows you to manage the pool of attributesassociated with a taxonomy table in Taxonomy mode. In MDM, attributes areassociated with – linked to – categories. Attributes then become associated withmain table records by assigning records to categories.

When you assign a record to a category, it acquires the attributes linked to thatcategory as well as the attributes linked to the parent category and all of the otherancestors of that category through inheritance. Thus a main table record consists



of common fields, inherited attributes, and category-specific attributes. You canmodify the attributes themselves as well as the set of attributes linked to anyspecific category in MDM using Taxonomy mode.

Figure 51: MDM Data Manager - Taxonomy Attributes

Text attributes are like a “mini” ookup tables. A pick list forces users to choosefrom a set of specific text values during data entry.

MDM also supports two predefined composite data types: Measurement fieldsand attributes.

Each measurement consists of two components: (1) a numeric value; and (2) aunit of measure.

Coupled numeric attributes. A coupled numeric attribute is a composite data typethat consists of pairs of measurement values.

A main table field is created in MDMConsole and applies to all of the records in anMDM repository. By contrast, an attribute is created and linked in the MDMClientin Taxonomy mode and applies just to records in categories to which the attributeis linked. The table below highlights the similarities and differences betweenfields and attributes that affect how they appear and are used within MDM.

Field Attribute

General

Created in MDM Console. Created in the MDM Client inTaxonomy mode.

Represents a schema change, so theMDM repository must be unloaded toadd a field.

Does not represent a schema change;the MDM repository must be loadedto link an attribute.



Category-independent; applies to allmain table records

Category-specific; applies just to maintable records in categories to which theattribute is linked; cannot be linked tothe taxonomy root.

Fields appear in schema order andcannot be hidden in the Record Detailtab.

Attributes appear in priority order inthe Record Detail tab – and can behidden entirely – on a per categorybasis based on the link priority.

Included in both the Records grid andRecord Detail tab; always of interesteven with large record sets.

Not included in Records grid; includedin Record Detail tab only for theselected records; generally of interestonly when you select a single orseveral main table records.

Text Values (not limited to a set of specific values)

Text field; used to permit data entry ofa unique value for each record.

No corresponding attribute type thatpermits entry of a unique value foreach record.

Text Values (limited to a relativelysmall set of specific values enumeratedin advance)

Lookup field into a flat table; picklist forces user to choose from a setof specific lookup values during dataentry.

Text attribute (like a “mini” lookuptable); pick list forces user to choosefrom a set of specific text values duringdata entry.

The lookup table record correspondingto each lookup value can contain anynumber of userdefined fields.

Each text value consists of: (1) afixed-width Text field for the textvalue itself; (2) a Text Large field forthe text value description; and (3) asingle-valued Image field for the textvalue image.

Supports both drilldown search andfree-form search.

Supports drill-down search; does notsupport free-form search.

Numeric and Measurement Values

Numeric and Measurement Values Numeric attribute with or without adimension. Supports drill-down searchusing a pick list of unique numericvalues; does not support free-formsearch.



Supports free-form search; does notsupport drilldown search.

Supports drilld-own search using apick list of unique numeric values;does not support free-form search.

Coupled Numeric Values

No field type for representingtwo-dimensional data.

Coupled numeric attribute; used forrepresenting two-dimensional data.

From a design standpoint, sparsity of data is less important than whether the dataitem applies to all main table records (should be a field) or just some subset(should be an attribute). For example, you may not have a Weight value for everyproduct, but weight certainly applies to every product and therefore should mostlikely be a field.



Exercise 1: MDM Field Types & FieldProperties

Exercise ObjectivesAfter completing this exercise, you will be able to:• Recap some key facts of different table and field types and properties

Business Example

Task:Please answer the following questions:

1. What are the main table types available for defining a repository schema?

2. What are the consequences of declaring a field to be “Display” on a lookuptable?

3. What are the differences between hierarchical tables and taxonomy tables?What table types can hierarchical tables be attached to? What table typescan taxonomy tables be attached to? What are common uses of hierarchicaltables and taxonomy tables?

4. Attributes are assigned to what type of table? What nodes can attributes beattached to? What is attribute inheritance?

5. Can a product (or customer, or vendor, etc., depending on the main tabletype) be assigned to more than one place in a taxonomy? If it can be assignedin multiple places how do you do it? If it cannot be assigned in multipleplaces, why not?

6. What is key mapping used for and how is it defined? What are the steps forthe import manager and data manager?

7. What is the purpose of non-qualified field in a qualified table? What is theminimum number of non-qualified fields required in a qualified table?

8. What is a tuple?

9. What is the difference between a simple tuple and a nested tuple? What typeof fields are used for each?

10. What fields are supported by Qualified Look-up tables, but not supported bytuples? What fields are supported by tuples but not by Qualified Look-uptables?

11. In terms of data modeling, tuples are more efficient and use less memorythan Qualified Look-up tables. Please explain.



Solution 1: MDM Field Types & FieldPropertiesTask:Please answer the following questions:

1. What are the main table types available for defining a repository schema?

a) Main, Flat, Qualified, Sound, Video, Hierarchy, Taxonomy, BinaryObject (see table type selection list under Console for creating a newtable).

2. What are the consequences of declaring a field to be “Display” on a lookuptable?

a) Display field(s) is what is displayed to the user when viewing the fieldfrom a parent table (i.e., main table record with field that is a lookup).This also impacts what is required to be mapped in the import manageras this “acts” similar to a key field (again only true when mapping fromthe perspective of the main table to a lookup field). All tables musthave at least one field as Display.

3. What are the differences between hierarchical tables and taxonomy tables?What table types can hierarchical tables be attached to? What table typescan taxonomy tables be attached to? What are common uses of hierarchicaltables and taxonomy tables?

a) Taxonomy tables have the capability to have attributes assigned;hierarchical does not support any attribute assignment. Hierarchicaltables can be attached to the main, flat, qualified, and taxonomy tables(as well as hierarchical). Taxonomy tables can only be attached to themain table.

Hierarchical tables would be used to provide for “roll-up” capabilityof data records for grouping purposes such as vendors (many storelocations under a common parent). Taxonomy tables are used toclassify the main records into groups that can be “drilled” into and thento have specific attribute properties assigned based on the classification.

Continued on next page



4. Attributes are assigned to what type of table? What nodes can attributes beattached to? What is attribute inheritance?

a) Attributes are only assigned to a taxonomy table. Once a main recordis assigned to a taxonomy, the attributes are then associated to theproduct for value assignment, but the attributes are not part of the maintable. Attributes can be assigned to any node in the taxonomy. Sincemain records are assigned only to the bottom node of a taxonomystructure, any attributes that are associated to nodes on the branch arealso assigned via “inheritance” to the main record.

5. Can a product (or customer, or vendor, etc., depending on the main tabletype) be assigned to more than one place in a taxonomy? If it can be assignedin multiple places how do you do it? If it cannot be assigned in multipleplaces, why not?

a) No, only one assignment of a main record can be made in a taxonomy.However, an alias can be created in the taxonomy that provides for theability to drill down multiple branches and come to the same node withthe main records assigned. However, main records cannot be assignedto an alias – they are assigned to the original node only.

6. What is key mapping used for and how is it defined? What are the steps forthe import manager and data manager?

a) Key mapping is used to identify the key field values for an MDMremote (MDC) system. The key mapping provides for the ability ofMDM to consolidate duplicate records from multiple systems (andfrom a single system) into a single MDM record. This way, all thefields can be maintained only once and then sent to each respectiveMDC system and record.

The key mapping is turned on when defining the table in the consolemanager. In the import manager, key mapping is applied by the remotesystem by mapping the respective key field to the key mapping field(designated with a key symbol) on the table (each map is based onwhat MDC is selected during the startup of the import manager). In thesyndicator, a similar process is followed – the key field is mapped tothe respective field in the MDC. The selection of the key field value inboth the syndicator and import manager is determined by the remotesystem selected in the map.

7. What is the purpose of non-qualified field in a qualified table? What is theminimum number of non-qualified fields required in a qualified table?

a) The non-qualified field(s) provide for the linkage between the maintable and the qualified table. A Qualified table must have at least onenon-qualified field defined.




8. What is a tuple?

a) A tuple is a record template that groups together a set of related fieldsinto a reusable object or type definition that describes or composes aparticular object or type.

9. What is the difference between a simple tuple and a nested tuple? What typeof fields are used for each?

a) A simple tuple does not contain a tuple field. A nested tuple contains atuple field, which makes it easy to create deeply nested structures.

10. What fields are supported by Qualified Look-up tables, but not supported bytuples? What fields are supported by tuples but not by Qualified Look-uptables?

a) Fields supported by Qualified Look-up tables but not by tuples:

Create Stamp, Time Stamp, User Stamp, Currency, Text Normalized,Calculated Field.

b) Fields supported by tuples but not by Qualified Look-up tables:

Text Large, Lookup main, Tuple

11. In terms of data modeling, tuples are more efficient and use less memorythan Qualified Look-up tables. Please explain.

a) Tuples store data directly in a record, where as, Qualified Look-uptables require separate lookup tables. The separate look-up tables usemuch more space and memory. Also, Qualified Look-up tables do notsupport nesting.



Exercise 2: Add fields to delivered MaterialMaster Repository

Exercise ObjectivesAfter completing this exercise, you will be able to:• Add fields to an SAP ERP Material Master by using the appropriate field

and table types.

Business ExampleThe currently delivered Material master repository does not contain all fieldsof the SAP ERP Material Master. A company has the requirement to maintainQM-settings for a material (QM-View in SAP ERP). When you have a look at theQM settings of the ERP Material Master, you can see that the QM settings aremaintained in dependency of a plant and an inspection type.

Example 1 for above business case:

The material 60-100F for the plant Berlin requires Quality Inspections duringproduction. A Quality Inspection during production for this material in this plantidentified the following:

• the percent of the produced goods need to be inspected• there is no 100% inspection required• the average duration of an inspection takes 1 day

Example 2 for above business case:

1. Plant Berlin

The material 100-300 requires

Quality Inspections during Goods Receipt and Stability inspections.

A Goods Receipt Quality Inspection for this material in this plant is defined thefollowing:

• the percent of the produced goods need to be inspected• there is no 100% inspection required• the average duration of an inspection takes 5 days

A Stability Inspection for this material in this plant is defined the following:

• 1 percent of the produced goods need to be inspected• 100% inspection is required• the average duration of an inspection takes 4 days

2. Plant Chicago



The material 100-300 requires

Quality Inspections during production. An Inspection during production forthis material in this plant is defined the following:

• percent of the produced goods need to be inspected• no 100% inspection is required• the average duration of an inspection takes 3 days

In a simplified XML-notation this would look like the following:



Task:

Figure 52: XML Notation

The QM settings are maintained in dependency of a Plant and Inspection type.This is the common principle for each material master.

From and MDM point of view, this would mean that the material master needs tobe enhanced by a Tuple, QM Settings, assigned to the Main table. Alternatively,the enhancement to the repository could be effected with a Qualified Table, wherethe fields Plant and Inspection Type would be created as non-qualifiers and thequalifiers would be Inspection Percentage, 100% Inspection Required andAverage Duration.

Enhance the Material Repository so that the QM settings for a material can bemaintained.

1. Start SAP MDM Console. Mount and select your server. Unload therepository.

Use the MDM Repository, MDM400MAT1_Start_# as the starting point foryour work.

2. Create LookUp Tables.

The Look Up Table Plants already exists in the repository.




Create a Look Up table for Inspection Types.

Note: Inspection Types are defined in ERP customizing. This tablecould be populated automatically using extraction and import.

3. Create a Tuple, QMSettings, to store all the QM relevant data for a materialmaster. Link the tuple to the main table by creating a tuple field, QMSettings, on the Products table.

4. Load the repository: MDM400MAT1_Start_# and verify your work

5. Create a Qualified table, QM Settings, to store all the QM relevant data fora material master. Link the Qualified table to the main table by creating aLookup [Qualified Flat] field, QM Setting, on the Products table. Optional

Note: The enhancement could be accomplished with a Qualifiedtable. The following step directs you on how to create thatenhancement. It is optional.



Solution 2: Add fields to delivered MaterialMaster RepositoryTask:

Figure 53: XML Notation

The QM settings are maintained in dependency of a Plant and Inspection type.This is the common principle for each material master.

From and MDM point of view, this would mean that the material master needs tobe enhanced by a Tuple, QM Settings, assigned to the Main table. Alternatively,the enhancement to the repository could be effected with a Qualified Table, wherethe fields Plant and Inspection Type would be created as non-qualifiers and thequalifiers would be Inspection Percentage, 100% Inspection Required andAverage Duration.

Enhance the Material Repository so that the QM settings for a material can bemaintained.

1. Start SAP MDM Console. Mount and select your server. Unload therepository.




Use the MDM Repository, MDM400MAT1_Start_# as the starting point foryour work.

a) Select MDM400MAT1_Start_# and access the repository. Right mouseclick on the repository and choose the option, Connect to Repositorywith pw=Admin and make sure the repository is unloaded.

Note: You may need to Unarchive the repository,MDM400MAT1_Start_#. Select Unarchive from the contextmenu of your server. When prompted enter database user, dba,and database password, training. Name your new repositoryMDM400MAT1_Start_#, where # is your Group letter.

b) Expand the repository structure in the Console Hierarchy by expandingthe MDM400MAT1_Start_# repository in the Console Hierarchy onthe left side of the screen.

2. Create LookUp Tables.

The Look Up Table Plants already exists in the repository.

Create a Look Up table for Inspection Types.

Note: Inspection Types are defined in ERP customizing. This tablecould be populated automatically using extraction and import.

a) Create Lookup Table InspectionType.

Table Name Inspection Type

Type Flat

Key-mapping Yes

b) Rename field “Name” in the table to “Type”.

c) Create the following additional field in the table

Field Name or Data Type Values

Code – Text(6) Display Field=Yes, leave allother flags to the default values




3. Create a Tuple, QMSettings, to store all the QM relevant data for a materialmaster. Link the tuple to the main table by creating a tuple field, QMSettings, on the Products table.

a) Select the Products Table in the Console Hierarchy.

Add new field:

Field Name QMSetting

Type Tuple

Multi-valued Yes

Tuple QMSettings

Shift+Enter to Save field.

b) Load Repository and verify your work. Load the repository:MDM400MAT1_Start_#.

Note: In case you had problems with the exercise,unarchive the file MDM400MAT1_Solution_# asMDM400MAT1_Solution_# and then load the repository afterthe unarchive job is finished.

4. Load the repository: MDM400MAT1_Start_# and verify your work

a) Launch the MDM Data Manager and connect to repository:MDM400MAT1_Start_# (or in the case you had problems with theexercise connect instead to MDM400MAT1_Solution_#.

User Admin

Password no password

5. Create a Qualified table, QM Settings, to store all the QM relevant data fora material master. Link the Qualified table to the main table by creating aLookup [Qualified Flat] field, QM Setting, on the Products table. Optional

Note: The enhancement could be accomplished with a Qualifiedtable. The following step directs you on how to create thatenhancement. It is optional.

a) Select the repository in the Console Hierarchy. Right click and fromthe context menu, choose the option Add Table.

Use QM Settings for the name and QM_Settings for the code.

Choose the type Qualified Flat from the drop down. Use the keycombination Shift + Enter to save the new table.




b) In the Console Hierarchy, select the Qualified table QM Settings andright click to choose the option Add Field.

Use Plant for the name and Plant for the code.

For the property “Qualifier”, do not change the default.

Choose the type Lookup [Flat] from the drop down and choose thetable Plants from the drop down for the table. Use the key combinationShift + Enter to save the new field.

c) In the Console Hierarchy, select the Qualified table QM Settings andright click to choose the option Add Field.

Use Inspection Type for the name and Inspection_Type for the code.

For the property “Qualifier”, do not change the default.

Choose the type Lookup [Flat] from the drop down and choose thetable Inspection Types from the drop down for the table. Use the keycombination Shift + Enter to save the new field.

d) In the Console Hierarchy, select the Qualified table QM Settings andright click to choose the option Add Field.

Use Inspection Percentage for the name and Inspection_Percentagefor the code.

For the property “Qualifier”, use the dropdown to choose the optionYes.

Choose the type Text from the drop down. Use the key combinationShift + Enter to save the new field.

e) In the Console Hierarchy, select the Qualified table QM Settings andright click to choose the option Add Field.

Use Average Duration for the name and Average_Duration for thecode.


Choose the type Measurement from the drop down. Choose theDimension Time with default unit days.

Use the key combination Shift + Enter to save the new field.

f) In the Console Hierarchy, select the Qualified table QM Settings andright click to choose the option Add Field.

Use 100% Inspection Required for the name and100%_Inspection_Required for the code.





Choose the type Boolean from the drop down. Change the True to Yesand the False value to No.

Use the key combination Shift + Enter to save the new field.

g) Select the Products Table in the Console Hierarchy.

Add new field:

Field Name QMSetting

Type Lookup [Qualified Flat]

Multi-valued Yes

Table QMSettings

Shift+Enter to Save field.



Lesson Summary

You should now be able to:• Explain the different field types in MDM.• Explain the different field properties in MDM.


MDM400 Unit Summary

Unit SummaryYou should now be able to:• Describe the different table types in MDM.• Explain how the different types of tables are used in MDM.• Describe the properties assigned to MDM tables.• Explain how the different table properties are used in MDM.• Explain the different field types in MDM.• Explain the different field properties in MDM.


Unit Summary MDM400


Unit 3MDM Data Modeling Practice

Unit OverviewYour company plans to implement MDM. To get first experience with the MDMData Modeling approach, you were tasked to develop a data model for businesspartners.


• Explain how MDM data modeling differs from traditional data modelingapproaches

• Perform the appropriate steps to define a MDM data model• Explain how to differentiate a well-defined data model from a data model

with limitations• Learn best practices before starting the definition of a Data Model• List the various tips to solve specific problems that usually occur in many

projects• Explain how to avoid pitfalls that might cause problems at a later point in

time

Unit ContentsLesson: MDM Data Modeling Procedure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Exercise 3: Steps to Perform to Develop a MDM Data Model.. . . . . . . . 89Lesson: MDM Data Modeling Best Practices ... . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

Exercise 4: MDM Data Modeling Best Practices ... . . . . . . . . . . . . . . . . . . . .125Lesson: MDM Data Modeling Issues and Solutions... . . . . . . . . . . . . . . . . . . . . .130


Unit 3: MDM Data Modeling Practice MDM400

Lesson: MDM Data Modeling Procedure

Lesson OverviewThis lesson illustrates the various approaches to data modeling and how MDMdata modeling differs from traditional data base modeling techniques. The lessoncontinues to outline the steps for appropriate MDM data modeling.


• Explain how MDM data modeling differs from traditional data modelingapproaches

• Perform the appropriate steps to define a MDM data model• Explain how to differentiate a well-defined data model from a data model

with limitations

Business ExampleA company would like to consolidate their business partners using a master datamanagement solution. There is an uncertainty on which kind of data is reallymaster data and what is not. Different people have different opinions on it.

Traditional Approaches to Data Modeling

Figure 54: What Is Used as a Basis to Start with?


MDM400 Lesson: MDM Data Modeling Procedure

Figure 55: Conceptual Data Modeling

Conceptual data models, sometimes called domain models, are typically usedto explore domain concepts with project stakeholders. Sometimes high-levelconceptual models are often created as part of your initial requirements envisioningefforts as they are used to explore the high-level static business structures andconcepts. Conceptual data models are often created as the precursor to LogicalData Models (LDMs) or as alternatives to LDMs.

Figure 56: Logical Data Models

Logical data models (LDMs) are used to explore the domain concepts, and theirrelationships, of your intended domain. This could be done for the scope of asingle project or for your entire enterprise. LDMs depict the logical entity types,typically referred to simply as entity types, (sometimes called “strong entities”; the



data attributes describing those entities, sometimes called “weak entities”; and therelationships between the entities, sometimes called “collision points”. LDMs areoften used on traditional projects as a way of extending the conceptual data model.

Figure 57: Physical Data Models

Physical data models (PDMs) are used to design the internal schema of a database,depicting the data tables, the data columns of those tables, and the relationshipsbetween the tables. PDMs often prove to be useful on traditional data modelingprojects as the result is on physical modeling.

Although LDMs and PDMs sound very similar, and they in fact are, the level ofdetail that they model can be significantly different. This is because the goals foreach diagram is different – you can use an LDM to explore domain concepts withyour stakeholders and the PDM to define your database design. The graphicsabove present a simple LDM and a simple PDM, both modeling the concept ofcustomers and addresses as well as the relationship between them. The PDMshows greater detail, including a table required to implement the association aswell as the keys needed to maintain the relationships. PDMs can also reflect anorganization’s database naming standards, in this case an abbreviation of the entityname is appended to each column name and a number or id field was consistentlyintroduced. A PDM should also indicate the data types for the columns, suchas integer and char(5). The graphic for the PDM imply lookup tables (alsocalled reference tables) for how the address is used as well as for states andcountries are implied by the attributes ADDR_USAGE_CODE, STATE_CODE,and COUNTRY_CODE.

The table below compares these three types of data models:



Feature Conceptual Logical Physical

Entity Names X X

EntityRelationships

X X

Attributes X

Primary Keys X X

Foreign Keys X X

Table Names X

Column Names X

Column DataTypes

X

Figure 58: What is the Data Modeling Approach in MDM?

Explain importance of primary key, display fields, unique constraints.



Figure 59: How to Identify an Optimized Data Model

During data modeling the boundaries of the MDM data modeling capabilities needto be considered. Often customers try to bend the functionality to make it work fortheir requirements. This often causes problems later on, e.g. with either navigationin the MDM Data Manager or import performance with large volumes of records.

In general, you can say that if you can easily find the complete information you arelooking for in the data manager, the model is well defined. Vice versa you can say,that e.g. using work-arounds (such as pointing to other fields in the Data Managerfor building of Relationships) sometimes cause problems from a navigational pointof view in the Data Manager and tells you that the data model has some limitations.

Often you come up with several different data model approaches. Performing thenthe above checks can give you direction on which one is the best fit.

Data Modeling in SAP MDMThis section presents general guidelines for designing an MDM repository.However, there are no hard-and-fast rules, and good judgment is involved nearlyevery step of the way. Ultimately you will want a repository design that optimizesease of maintenance (for you) and ease of searching (for your customers).Increased granularity and structure of the data will make it easier to maintainthe repository; well thought-out categories and attributes will make it easier tosearch it.



Figure 60: Data Modeling in SAP NetWeaver MDM 1

Identifying the main table objects for your repository is the entry step into defininga data model. Since it is currently possible to have multiple main tables perrepository, it is crucial to select the right object for each of the main tablesTry not to confuse weak entities, discussed in the section above, with strongentities. Strong entities are, in many cases, capable of standing alone, without alarge number of support tables, although in the concept of a repository, detailedstructures are often the most useful.

The main table objects represent the main objects for your business. Similarly,you can ask what result set the system is to deliver when you perform a searchfor such objects.

Now that multiple main tables are permitted in a repository, having one repositoryincorporating several domains or one repository/domain is the big question. Youshould consider having several main tables in a repository when:

• Each main table is an entity of its own (like vendor, customer, material, etc.).• The object types in each main table can be clearly differentiated from each

other.• Multiple main tables are related with each other for business reasons or that

they share the same commonly used data from lookup tables, e.g. Plantcodes, Countries etc.



Figure 61: Multiple Repository Domains - Considerations

Locating multiple domains in a single repository can also benefit from thefunctions and features that are available inside a single repository. Workflows,assignments and validations are available over multiple main tables in the samerepository, but they do not span different repositories.



In order to make the right decision three different areas need to be considered.These are the Console, Read/Write operations and scenarios:

• Considerations in the Console A downtime (e.g. repository maintenance)will impact all main tables. Since several domains are in one and thesame repository, all these domains would be affected when the repositoryis unloaded.

• Performance impact (like load time of the repository) The more recordsand tables you have in your repository the more time it takes to load it.Similar impact would be when it comes to updating or inserting new recordsinto the repository. Indexes need to be rebuilt etc.

• Considerations for Data Entry (CRUD operations) There would bean increase in the number of users working with multiple main tables inone repository. More domains in a repository typically means also moreconcurrent users working in the repository. In repositories where users haveRead/Write authorizations, this could lead to potentially more locking issues.

• Scalability for large number of records in repository The more recordsthere are in your repository and the more users are working concurrently withyour repository, the more powerful your machine has to be.

• Consider the impact of imports, syndications and synchronizations Forrepositories having multiple domains – this would probably mean more ormore often performing these operations

• Considerations from a Scenario perspective

– Separation of operations: If there’s one domain with read/write accessrequired and another domain only with read access required, these twodomains should go into separate repositories.

– Keep Business scenarios is separate repositories: e.g. CMDM(Central Master Data Management) and MDM-GDS (Global DataSynchronization) both should their own repository.

The above list provides a good starting point when it comes to making the decisionof single domain repositories as opposed to . multi-domain repositories. Often itwill be also required to develop a prototype to see whether all requirements can behandled with the one or the other strategy.

For example, a company sells its own products and also other products it procuresfor sale as a reseller. Many of these latter category of products can be orderedfrom several different suppliers. In this case, the main table objects can be eitherthe product itself with a sub-table for suppliers or the combination of productsand suppliers. If certain information is maintained as supplier-specific, thenthe main table objects should be the product/supplier combination as two maintables where the products main table refers to the suppliers main table or possiblymutually referable.




Define for each field of the catalog how the data should be stored in the catalog –as a numeric value like integers or real numbers, as currency, as measurement,as text or images, whether the field should be a single-valued or multi-valuedand whether it should be a lookup field.

Decide the type of each field of a repository. If a field is designed to be alookup field (a field which takes its legal values for data entry and search froma corresponding lookup table), then decide if the corresponding lookup tableshould be flat, hierarchical, taxonomy or qualified. Then each lookup field inthe main table becomes a searchable dimension of the repository and appearsautomatically in the MDM Data Manager as a search tab in the Search Parameterspane in Record mode.

In regard to search strategies, turning on every search option one runs across in arepository is not a useful strategy. In MDM terms, searchability implies the use ofsearch indexes which must be loaded into memory when the repository is loaded.

For instances, the Keyword field property indicates whether or not a field’scontents are included in the MDM repository’s built-in keyword search index. Thisindex is used to match words entered in an MDM application’s keyword searchparameter to records in the current table. When users perform a keyword search,MDM uses the Inxight stemming engine to extract the stems of their search words.This allows MDM to match the searched-for keyword to records containingthe same stem as the search word but having different suffixes. For example,a keyword search for the word “walking” will match records containing thekeywords “walks” and “walked” in the table’s keyword-indexed fields, since thesearch word and all of the keywords have the same stem, “walk.” Be aware that itis neither necessary nor recommended to keyword every field on the table. Rather,keyword only those fields which use a small set of unique words across all records(or small relative to the total number of records). A Description field is an exampleof such a field; even though the total number of words used across all records will



be large, the number of distinct words will likely be small. By contrast, you shouldnot keyword a Part Number field because it is likely to contain a different valuefor every record. Also, you should not keyword fields which contain informationthat is so generic that a keyword search returns too many records to be useful.

There are two types of search in the MDM Data Manager: Drilldown Search andFree-Form Search. With Drilldown search, you can make selections from eachsearch tab, where each tab corresponds to a lookup field in the table (such asManufacturer or Category). You can also make selections for each of the attributeslinked to the selected category, and each of the qualifiers of a qualified tablerecord. You can make selections in any order, to constrain the search results andconverge on one or more products, and you can also remove search selections inany order to expand the set of search results and find similar products. At eachstep along the way, the system narrows down the choice of values for each searchdimension to show only those that are valid given the current result set based onthe previous search selections. This is known as limiting and guarantees that youcan never go down a dead-end path. For example, if you select “Chain Saws” inthe Category tab, and then open the Manufacturer tab, only the manufacturersof chain saws will be listed. The result is an extremely flexible and powerfulsearch capability, delivered through an exceptionally smooth and intuitive process.Limiting makes it easy to detect errors in your master data, when values thatshould not be part of the search results show up in the limited list of existing fieldor attribute values. With Free-Form search, you can perform searches on any fieldthat does not lookup its values from a subtable. Free-form search also allows youto do “fuzzy” searches with a variety of search operators; however, the down sideof this approach is that you can also end up with no matching records, whichcannot happen with drilldown search.




Pricing for materials, e-mail addresses or phone numbers for customers are waysto model 1:n relationships from a main table record to a lookup table record.

If table records are somehow related together (e.g. storage locations as main tableobjects – locations belong to states, states can belong to regions, regions belong tocountries), this can be covered in a hierarchy table.

Compared to normal lookup tables a hierarchy table provides additional structure– representing the relationship between different records. This way of structuringmakes it also easier to find later-on records in lookup tables. Going back to theexample about different locations if there are several hundred location recordsstored in a lookup table it will be complicated to find the right one for selection,while if everything is structured in a hierarchy table you can easily drill-down tofind the right location starting e.g. with the country, going down to the region, etc.

Lookup fields can appear not only in the main table but also within any of thelookup tables themselves, such as when the Manufacturer field in the main table isa lookup into the Manufacturers table of legal manufacturer names, and the Statefield in the Manufacturers table is in turn a lookup into the States table of legaltwo-letter state abbreviations. In the MDM Client, each lookup field in a lookuptable appears not only as a search tab when the current table is the lookup table,but also within the search tab for the main table lookup field when the current tableis the main table, for multi-level “search-within-a-search.” A single nested lookupfield allows the main table lookup field to support search-within-a-search. Multiplenested lookup fields not only support search-within-a-search, they also allow thelookup table to act as a valid table that defines specific value combinations amongthe values of each of the multiple nested lookup fields. Like all MDM drilldownsearches, multi-level search-within a-search is omnidirectional; that is, you canmake nested lookup field value selections in any order and intermingle them withselections made from other search dimensions.

Taxonomy tables can be used if you have to classify records according to certainattributes. Here, it is not required that each of the records has the same attributes.By assigning a main table record to a certain taxonomy class, the respectiveattributes for the record are determined automatically.

Taxonomies can be defined only for the main tables. Even when it is possible tohave several taxonomies for a main table, it is recommended to define only onetaxonomy.




Unique fields: Even when it is not mandatory for a repository, some fields shouldbe defined as unique. Unique fields are useful to avoid redundancy within therepository plus they can be used in the import manager to perform the matching.Very often matching is performed on a remote key. However, a matching can beperformed also based on a unique key. A typical use-case for such a matchingwould be e.g. the load of records from a legacy system into MDM with followingshutdown of the legacy system (in this case storing of key-mapping would notbe necessary). To find the right records in the MDM system, you could perfomthe matching based on a unique field. It is suggested that text data type fieldsused as identification fields should use the “Unique” field property to preventduplicates. Note that his property does not preclude multiple fields from havingthe “Null” value.

Unique fields can also be tied together in the Console. Example: There are twounique fields product ID and manufacturer. By tying them together, not each fieldfor itself needs to be unique, but the combination of both fields must be unique.

There are two considerations of remote keys used in MDM:

• Remote keys to store information on a specific record in the remote systems.These keys can be set automatically by the import manager during dataimport or manually in the data manager either calling the key-mappingfunctionality or merging records together.

• Remote keys are performance sensitive – so use them wisely and only ifneeded.




Qualified tables are also used e.g. to model 1:n relationships from a main tablerecord to a lookup table record (samples are pricing for materials, e-mail adressesfor customers, phone numbers for customers)

In case there are simple relationships between records, these can be modeled byusing the predefined Relationship tables in a repository. Simple means that besidesthe relationship itself, a position, a quantity, and a mandatory flag can be defined.However, it is not possible to define a validity for a relationship.

• Example 1: Part A replaces Part B starting from April 1, 2007.• Example 2: Part A can be cross-sold with Part C starting from March 1,

2007 – March 31, 2007.

To define models for above examples, it is necessary to use a work-arounddefinition for relationships.

A main table field is created in MDM Console and applies to all of the records inan MDM repository. By contrast, an attribute is created and linked in the MDMData Manager in Taxonomy mode and applies just to records in categories towhich the attribute is linked. When it comes to determining attributes from adesign standpoint, sparsity of data is less important than whether the data itemapplies to all main table records (should be a field) or just some subset (should bean attribute). For example, you may not have a Weight value for every product,but weight certainly applies to every product and therefore should most likelybe a field.

In the context of tables, a tuple is like a table without an instance of the tableitself; more precisely, the definition of a tuple is like the definition of a table thateffectively groups together and names a set of related fields (where each recordconforms to that type definition), but without the actual storage container forthe records of the table. And whereas the tuple definition that is implicit in thedefinition of a table cannot be reused, a tuple can be defined once and reusedmany times within multiple tables across a repository. Note that both table andtuple definitions create a template for the fields of the corresponding table ortuple records, respectively. But whereas you can create and store table recordsimmediately after the table is defined, you can create and store tuple records onlyafter the tuple is subsequently referenced as a field in the definition of a real table.



A single-valued tuple reference does offer: (1) reusability, so that unlike atable definition, a tuple can be defined once and reused many times; and (2)encapsulation, so that subsequent changes to the tuple definition or its associatedproperties are immediately propagated to every use of the tuple. A multi-valuedtuple field is like a private table-within-a-table, in that each record of thereferencing table can “contain” multiple tuple records, allowing MDM to expressa one-to-many relationship in a very natural way. Alternatively, if you need a fixednumber of instances, you can simply include multiple references to the same tuplein a single record (e.g. Billing Address and Shipping Address).

MDM has historically included many different data modeling structures, eachof which was well-suited and optimized for a different set of data modelingchallenges. Each structure had its own particular – and often unique – propertiesand semantics around definition, data entry, navigation, and search. And each wasrelatively rigid and suffered from both a lack of generality and various limitationson when it could be used. By contrast, the tuple data structure is a basic buildingblock that subsumes, completely generalizes, and dramatically enhances thesestructures as follows:

Capability Tuples Qualified Par-ent/Child

Hierarchy

Hierarchical main tableentity

X

Include qualifiedinformation

X X

Qualify reference toany table

X

Reference records ofsame table

X X X

Reference records ofdifferent table

X X X

Multi-level nesting X X X

Bidirectionalnavigation

X X

Bidirectional visibility X X



A qualified lookup allows you to reference the records of a qualified lookup table,and also to further “qualify” the reference by storing additional link-specificinformation in fields known as qualifiers. By contrast, including the lookup to whatwould previously have been the qualified lookup table among the fields of a tuplerather than adding qualifiers to the definition of the lookup table allows you to:

• Extend to all lookup tables the specialized qualifier support previouslyoffered only by qualified lookup tables.

• Create a qualified reference to any normal lookup table, not just oneexplicitly and already defined as a qualified lookup table.

• Share the lookup table among different referencing tuple fields, each witha different set of qualifiers.

• Finally, in the degenerate case of no applicable table of lookup records, atuple without lookups can store a set of nested “link-specific” records withoutforcing the data modeler to create a “phantom” lookup table containing asingle record and a single non-qualifier field.

Note: Tuples generalize the concept of qualified lookup

Despite their flexibility, Relationships are hard to navigate and impossible tosearch, and can only be qualified with optional Required and Quantity fields ratherthan an arbitrary set of qualifiers. By contrast, including one or more lookupsinto the same or another table among the fields of a tuple provides an alternativefor modeling parent/child relationships, and allows you to include link-specific“qualified” information on every pair of related records.

Note: Tuples are an alternative to parent/child relationships that addfull qualifier support but do not offer the bidirectional navigation norbidirectional relationship visibility offered by parent/child relationships.

MDM tuples allow you to model flexible hierarchies and networks, complementinghierarchy lookups and tables with generalized support for hierarchical main tableentities. Specifically, by including one or more lookups into the same or anothertable among the fields of a tuple, you can express composite and arbitrarilycomplex relationships between similar and dissimilar business entities and alsoattach link-specific “qualified” information to every set of related records.

Note: Tuples generalize the concept of hierarchy management (trees >fully qualified hierarchies and networks) and extend support for hierarchylookups to support for hierarchical main table entities.

You can use either of two alternative approaches to modeling a hierarchy: (1)include a tuple with a lookup within the primary record (e.g. Org Chart); or (2)create a separate “links” table with multiple lookups and other fields (e.g. BOM).




Validations are useful to improve the Quality of your master data. One businesscase for validations is the syndication of master data into remote systems. Whensyndicating a material into a SAP ERP Central Component (SAP ECC) Clientsystem it is required that the unit of measure field is populated. Defining avalidation – which is called automatically during data maintenance in the MDMData Manager – you can make sure that the end-user has to maintain the UOM.

Other example can be to check that one or more fields of a record have the rightvalues

Normalization is the process of efficiently organizing data in a database. There aretwo goals of the normalization process: eliminating redundant data (for example,storing the same data in more than one table) and ensuring data dependenciesmake sense (only storing related data in a table). Both of these are worthy goalsas they reduce the amount of space a database consumes and ensure that datais logically stored.

For a database to be normalized, the following guidelines have to be observed:

1. Eliminate duplicative columns from the same table.2. Create separate tables for each group of related data and identify each row

with a unique column or set of columns (the primary key).3. Remove subsets of data that apply to multiple rows of a table and place

them in separate tables.4. Create relationships between these new tables and their predecessors

through the use of foreign keys.5. Remove columns that are not dependent upon the primary key.



It is important to point out that these are guidelines and guidelines only.Occasionally, it becomes necessary to stray from them to meet practical businessrequirements and performance. However, when variations take place, it'sextremely important to evaluate any possible ramifications they could have onyour system and account for possible inconsistencies.

The ultimate test of an optimal data model is its ability to efficiently import datainto the repository and successfully search for the data using various searchmodalities in the Data manager.



Exercise 3: Steps to Perform to Developa MDM Data Model

Exercise ObjectivesAfter completing this exercise, you will be able to:• Model a business partner repository.• Define a business partner model, based on a given ER diagram.• Create a data model, which makes maximum use of MDM table types

(lookup, qualified lookup, lookup hierarchy, etc).

Business ExampleFor the maintenance of business partners within MDM, your company wouldlike to create a data model. From your legacy system, an ER diagram is alreadyavailable, which should be used for the modeling.

Business Partners have a direct assignment to one or several products. Onebusiness partner (BP) can be a Class1 BP for the product steaks, while a Class2BP for the product hamburgers.

Task 1: Analyze Entity Relationships diagram.Before you start working in the MDM Console, have a close look at the attachedER Diagram, describing the different table types and relationships in Detail.

1. Analyze Entity Relationships diagram.




Figure 67: ER Diagram

Sample Data for better understanding

BPID BPNameType

BPName

BPType

Prod-uctLevel

BPClass

Sta-tus

BPLevel

9 01,LegalName

Ty-ChickEuropeLim-ited

Group

9 Labo-ratory

Ham-burg-ers,Prod-uctType,01.2.1.1

Class3 Ac-tive

Group

9 De-velop-ment

Soysausage,Prod-uctType,01.1.1.1

Class1 Ac-tive

Group




BPID BPNameType

BPName

BPType

Prod-uctLevel

BPClass

Sta-tus

BPLevel

9 Pro-duc-tion

Steaks,Prod-uctType,01.2.1.2

N/A Un-derRe-view

Group

10 01,LegalName

Bendy'sChicagoLabo-rato-ries

Sub-sidiary

10 02, In-ternalName

Bendy'sChi-Lab

Sub-sidiary

10 Pro-duc-tion


Class1 Ac-tive

Sub-sidiary

Explanation of entities

BP Name & BP Name types

A business partner can have different names, e.g. an internal name, amarketing name, a factory name, etc. Internal name, marketing name, etc. isconsidered the name type.

Product Levels

Describes the companies own product portfolio and how it is structured. EachProduct Level consists of a Product Level Code, Product Level TypeCodeand ProductLevelName. Product Levels can have children and parents.

Product LevelCode

Product Level Product LevelType

Parent LevelCode

1 GOPS Products

01.01.2009 Vegetarian Product Division 1

01.01.2001 Soyproducts Product Group 01.01.2009




Product LevelCode


Parent LevelCode

01.1.1.1 Soysausage Product Type 01.01.2001

01.1.1.2 Soymilk Product Type 01.01.2001

01.02.2009 Meat Product Division 1

01.02.2001 Beef Product Group 01.02.2009

01.2.1.1 Hamburgers Product Type 01.02.2001

01.02.2002 Pork Product Group 01.02.2009

01.2.2.1 Bellies Product Type 01.02.2002

01.2.2.2 Sausages Product Type 01.02.2002

01.03.2009 Kosher Product Division 1

01.03.2001 Seafood Product Group 01.03.2009

01.3.1.2 Fish Product Type 01.03.2001

BusPartner

Contains general business partner information like address info, etc.

BP Levels

Each BP has a certain level, describing the organizational character of the BPin more detail. Possible BP levels are e.g. Group, Subsidiary, Factory, Line,Retailstore. Two BPs can be in a relation to each other, e.g. Brazil Soy inManaos (is a subsidiary) and belongs to Brazil Soy global (Group).

BP Status & BP Statuses

Every BP has a status assigned to it, e.g. active, inactive, On Probation.

BP Class & BP Classes

Every BP has a certain Class assigned to it, e.g. Class1, Class2, Class3.Classes can be (according to the ER diagram related to each other, but wedo not consider this in the exercise).

BP Type & BP Types

Describes the type of BP, e.g. Development, Laboratory, Office, Production.This is not so much an organizational description, it can be seen rather froma logistics, supply chain perspective.

BP Product Level

Combines BP and product information together.




A business partner with the company can do business for different productlevels. Depending of the product level, the BP can be of a different type,e.g. the BP NutritionLabs can act for the product group Soyproducts asLaboratory, while for the ProductDivision Meat it can act as a productionfacility.

2. After careful analysis of the ER diagram, sketch on paper the structure ofyour repository.

Task 2: Implement the RepositoryImplement the repository in the MDM Console. Some tables for the repository arealready defined for you and can be reused.

Start with the repository: MDM400BP1_Start_#.

1. Start the SAP MDM Console. Mount and select your server

2. According to the diagram you need to create a hierarchy table for the productlevels.

3. According to the diagram you need to create a hierarchy table for the BPlevels.


5. According to the diagram you need to create a tuple for the BP Product levels.

6. According to the diagram, you need to add other fields to the main table,Business Partners.

7. Alternative Solution using Qualified Tables Optional

Task 3: Analyze the Results of your ImplementationTry to find answers for the following questions:

1. This is a question concerning the table “Product Levels”. Assuming, youhave defined your data model. Is it possible to make a BP assignment notonly to a product type but also to a complete product group or a productdivision?




2. As what do you define the field “ZIP-Code” in the Main table? Integer orText and why?

3. It should only be possible to save a new business partner record, whenat least one name has been entered for the business partner. How can thisbe accomplished?

4. In addition, we would like to perform some validity check for ZIP codes andStates. How can we make sure that ZIP Code and State are aligned so that byaccident no mismatches occur there?

Task 4:Review the implementation.

1. Load Repository and verify your work.



Solution 3: Steps to Perform to Developa MDM Data ModelTask 1: Analyze Entity Relationships diagram.Before you start working in the MDM Console, have a close look at the attachedER Diagram, describing the different table types and relationships in Detail.

1. Analyze Entity Relationships diagram.

Figure 68: ER Diagram

Sample Data for better understanding

BPID BPNameType

BPName

BPType

Prod-uctLevel

BPClass

Sta-tus

BPLevel

9 01,LegalName

Ty-ChickEuropeLim-ited

Group

9 Labo-ratory

Ham-burg-ers,Prod-

Class3 Ac-tive

Group




BPID BPNameType

BPName

BPType

Prod-uctLevel

BPClass

Sta-tus

BPLevel

uctType,01.2.1.1

9 De-velop-ment

Soysausage,Prod-uctType,01.1.1.1

Class1 Ac-tive

Group

9 Pro-duc-tion

Steaks,Prod-uctType,01.2.1.2

N/A Un-derRe-view

Group

10 01,LegalName

Bendy'sChicagoLabo-rato-ries

Sub-sidiary

10 02, In-ternalName

Bendy'sChi-Lab

Sub-sidiary

10 Pro-duc-tion


Class1 Ac-tive

Sub-sidiary

Explanation of entities

BP Name & BP Name types

A business partner can have different names, e.g. an internal name, amarketing name, a factory name, etc. Internal name, marketing name, etc. isconsidered the name type.

Product Levels




Describes the companies own product portfolio and how it is structured. EachProduct Level consists of a Product Level Code, Product Level TypeCodeand ProductLevelName. Product Levels can have children and parents.

Product LevelCode


Parent LevelCode

1 GOPS Products

01.01.2009 Vegetarian Product Division 1

01.01.2001 Soyproducts Product Group 01.01.2009

01.1.1.1 Soysausage Product Type 01.01.2001

01.1.1.2 Soymilk Product Type 01.01.2001

01.02.2009 Meat Product Division 1

01.02.2001 Beef Product Group 01.02.2009

01.2.1.1 Hamburgers Product Type 01.02.2001

01.02.2002 Pork Product Group 01.02.2009

01.2.2.1 Bellies Product Type 01.02.2002

01.2.2.2 Sausages Product Type 01.02.2002

01.03.2009 Kosher Product Division 1

01.03.2001 Seafood Product Group 01.03.2009

01.3.1.2 Fish Product Type 01.03.2001

BusPartner

Contains general business partner information like address info, etc.

BP Levels

Each BP has a certain level, describing the organizational character of the BPin more detail. Possible BP levels are e.g. Group, Subsidiary, Factory, Line,Retailstore. Two BPs can be in a relation to each other, e.g. Brazil Soy inManaos (is a subsidiary) and belongs to Brazil Soy global (Group).

BP Status & BP Statuses

Every BP has a status assigned to it, e.g. active, inactive, On Probation.

BP Class & BP Classes

Every BP has a certain Class assigned to it, e.g. Class1, Class2, Class3.Classes can be (according to the ER diagram related to each other, but wedo not consider this in the exercise).

BP Type & BP Types




Describes the type of BP, e.g. Development, Laboratory, Office, Production.This is not so much an organizational description, it can be seen rather froma logistics, supply chain perspective.

BP Product Level

Combines BP and product information together.

A business partner with the company can do business for different productlevels. Depending of the product level, the BP can be of a different type,e.g. the BP NutritionLabs can act for the product group Soyproducts asLaboratory, while for the ProductDivision Meat it can act as a productionfacility.

a) Try to first understand the ER. Perform the following steps:

• Identify the main table object on the ER diagram.• Identify the subtables.• Create a structure for the MDM repository on paper.

Success criteria for the repository:

• No Redundancies.

• Easy Navigation in the Data Manager.

2. After careful analysis of the ER diagram, sketch on paper the structure ofyour repository.

a) The solution on paper should be similar to the following:

Figure 69: Business Partners–Theoretical Solution using Tuples




The main table stores the Business Partners itself.

• A business partner itself can have a certain level, e.g. a Group,a factory, etc. Here, we select from a certain set of values, sothey should go in a lookup table. In our case, we decided to giveit some more structure and choose either a flat or hierarchy tablefor it.

• Since for each business partner several names are possible (e.ginternal name), the names should be stored in a tuple with the typeof the name as a lookup field.

• Theoretically, the business partner can have for each of theproducts in the companies product line, a different status, classand type. This is a typical 1:n relation, so it could go into a tuple.The linkage between the main table and the type, status, and classis established via the product level.

Task 2: Implement the RepositoryImplement the repository in the MDM Console. Some tables for the repository arealready defined for you and can be reused.

Start with the repository: MDM400BP1_Start_#.

1. Start the SAP MDM Console. Mount and select your server

a) Start SAP MDM Console. Select MDM400BP1_Start_# .

From the context menu, choose the option Connect to Repository.When prompted enter: user=Admin and pw=(blank).

The repository must be unloaded.

Expand the repository structure.




Figure 70: Repository Structure

2. According to the diagram you need to create a hierarchy table for the productlevels.

a) Create the Product Levels hierarchy table with following information:.

Table Name: Product Levels

Type: Hierarchy

b) Create the following Fields

Field Name or DataType

Values

Code – Text(20) Display Field=YesAll other parameters = default setting

Name – Text(50) Multilingual = NoAll other parameters = default setting

Product Level Type Code– Lookup(Flat)

Lookup TableProduct Level Types


a) Create a BP Levels hierarchy table with following information:

Table Name: BP Levels

Type: Hierarchy

b) Create or change the following fields.


ID – Integer All other parameters = defaultsetting

Name – Text(20) Multilingual = NoAll other parameters = defaultsetting

Code – Lookup(Flat) Lookup table = BP Level TypesAll other parameters = defaultsetting





a) A Tuple for the business partner names is needed. Create a tuple withthe following information:

Tuple name BP Names

Create or change the following Fields:

Type Code – Lookup (Flat) Display Field = Yes LookupTable = BP Name TypesAll other parameters = defaultsetting

Name – Text (50) Multilingual = No Display Field= YesAll other parameters = defaultsetting

Create a field which refers to the tuple on the main table BusinessPartner:

Name - Tuple Tuple= BP NamesMultivalue = Yes

Shift + Enter to save the field.

5. According to the diagram you need to create a tuple for the BP Product levels.

a) Create a tuple for BP Product Levels with the following information:

Tuple Name BP Product Levels

b) Create the following Fields:

Product Level – Lookup(Hierarchy)

Display Field =Yes Lookup Table= Product Level Leave DefaultSettings for other parameters

Type – Lookup (Flat) Lookup Table = BP TypesLeave Default Settings for otherparameters

Status – Lookup (Flat) Display Field = Yes LookupTable = Statuses Leave DefaultSettings for other parameters




Class – Lookup (Flat) Lookup Table = Classes LeaveDefault Settings for otherparameters

c) Delete the Name field

d) Create a field which refers to the tuple on the main table BusinessPartner.

Product Level-Tuple Tuple = BP Product LevelsMultivalue =Yes

e) Shift + Enter to save the field.

6. According to the diagram, you need to add other fields to the main table,Business Partners.

a) Add other fields to Main Table

Create a new fields in the main table with the following properties.


ID - Auto ID Display Field = Yes

Level - Lookup(Hierarchy) Display Field = No,Lookup Table=BP Levels

PrimaryPhone,FaxNumber,ZIP – All of them are Text(20)

Default properties

Street,City,State – All of them are Text(50)

Default properties

Street Number – Text(10) Default properties

b) Reorder the fields in the main table to your liking.




7. Alternative Solution using Qualified Tables Optional

a) The main table stores the Business Partners itself.

Figure 71: Business Partners–Theoretical Solution using QualifiedTables

• A business partner itself can have a certain level, e.g. a Group,a factory, etc. Here, we select from a certain set of values, sothey should go in a lookup table. In our case, we decided to giveit some more structure and choose either a flat or hierarchy tablefor it.

• Since for each business partner several names are possible (e.ginternal name), the names should be stored in a qualified lookuptable with the type of the name as a non-qualifer.

• Theoretically, the business partner can have for each of theproducts in the companies product line, a different status, classand type. This is a typical 1:n relation, so it should go into aqualified lookup table. The linkage between the main table andthe type, status, and class is established via the product level; theproduct level acts as the non-qualifier.




Task 3: Analyze the Results of your ImplementationTry to find answers for the following questions:

1. This is a question concerning the table “Product Levels”. Assuming, youhave defined your data model. Is it possible to make a BP assignment notonly to a product type but also to a complete product group or a productdivision?

a) Yes, this can be done in the data manager via creation on an internalleaf-node for a branch.

Figure 72: Data Manager

2. As what do you define the field “ZIP-Code” in the Main table? Integer orText and why?

Answer: The field is defined as Text, since there are also ZIP-Codescontaining a ‘-‘ possible.




3. It should only be possible to save a new business partner record, whenat least one name has been entered for the business partner. How can thisbe accomplished?

a) By defining a validation checking, whether the name-field is populated.

Figure 73: Properties

4. In addition, we would like to perform some validity check for ZIP codes andStates. How can we make sure that ZIP Code and State are aligned so that byaccident no mismatches occur there?

Answer: This could be done either by using a hierarchy, where Statesand Zip-Codes are stored in different levels (1. Select the state, then theZIP-Code) or by using a lookup within a lookup table.




Task 4:Review the implementation.

1. Load Repository and verify your work.

a) Load the repository.

1. Launch the MDM data manager:

Repository = MDM400BP1_Start

User = Admin

Password = “blank”

b) Enter values in the different table types; at first in the lookup tables,then in the main tables, then in the qualified lookup tables.

c) Check the search functionality for different BP records by means ofdifferent search options.



Lesson Summary

You should now be able to:• Explain how MDM data modeling differs from traditional data modeling

approaches• Perform the appropriate steps to define a MDM data model• Explain how to differentiate a well-defined data model from a data model

with limitations



Lesson: MDM Data Modeling Best Practices

Lesson OverviewThis lesson gives suggestions in the form of Best Practices when designing anMDM data model.


• Learn best practices before starting the definition of a Data Model

Business ExampleYour company plans to implement MDM and after evaluating the different optionson where to use MDM, you decided to implement first a solution to handleBusiness Partners. Since your companies Business Partner object is very unique toyour company, the SAP delivered Business content isn’t of much use, so there’s aneed to define a completely new data model for handling your Business Partners.

Data Modeling Best Practices

Figure 74: Lesson Learned: Repository Design 1


MDM400 Lesson: MDM Data Modeling Best Practices

Figure 75: Lessons Learned: Repository Design 2

Figure 76: Best Practices – Governance Model along with Data Model

Build a governance model for all parts of the master data object (even thoughthey will not be maintained or harmonized within MDM) and break it down toeach field.

With regards to the needs of the remote systems, carefully evaluate for whichfields it makes sense to keep in MDM.

Data Modeling does not only have a technical side, the processes need to beregarded as well!

Every field that is added to the data model brings complexity in terms of accesscontrol, validations, technical design of the field, and distribution. This isespecially important for Central Master Data Management scenarios.



For a pure consolidation scenario:

• Evaluate the data quality in the remote systems carefully• Pick the data elements providing a good quality to be used for matching

records during import• Map the data models• Keep the data model as slim as possible

Figure 77: Best Practices – Field Conformance

The implemented data model is a cornerstone and one of the most importantsuccess factors during the MDM implementation. It needs to be planned carefully!

Do not include fields in the data model for which the technical restrictions, thegovernance model, the dependencies to other parts of the object data and thevalidation rules have not been evaluated.

Unnecessary fields in the data model have a negative impact on performance.

Consider the authorization necessary to control the access to the MDM data, e.g.does the organizational structure need to be included in MDM?



Figure 78: Best Practices – Careful Planning

If the users need to have additional information to fulfill their tasks, which is notreally part of the master data, such as transactional data, avoid loading this datainto MDM. Instead try to use the Portal or a Web Service in order to expose thisinformation to the user.

Never use a quick-and-dirty approach during data modeling! Late changes mightcause extra effort (out of the total estimated task effort) on a lot of different partsof the solution, especially on custom-built applications and distribution.

Data modeling is a complex task, so be sure to estimate enough time during theproject to achieve the necessary quality.

Careful planning is not limited to the main table! All tables should exhibit carefulplanning with attention given to the selection of a table's display fields, sort andkeyword properties for fields.



Figure 79: Best Practices – Naming Conventions

Table names should be plural. The name of the table should not be replicated tothe fields, thereby causing confusion.

Figure 80: Best Practices – Keyword Search

The usage of the keyword search has a negative impact on performance, especiallyduring the loading and periodic maintenance steps of the repository.



Keyword search causes the MDM server to allocate more memory.

Carefully consider for each field if the keyword search is really necessary.

Try to limit the usage as much as possible in alignment with business requirements.

Figure 81: Best Practices – Sorted Fields

The usage of too many sorted fields has a negative impact on performance,especially during the loading and periodic maintenance steps of the repository.

Try to limit the usage as much as possible in alignment with business requirements.However, keep in mind that fields with a positive “Sort” property aid the importof records by making it easier for the Import Manager to determine a field'sdistinct values. The business requirements must be taken into consideration whenweighing the negative and positive aspects of applying this field property.



Figure 82: Best Practices – Display Fields

Display fields are used to create a non-technical key for the main object and thesub-objects and to determine the fields shown to the user in case of a lookuprelation.

Try to limit the amount of display fields you use, especially on the main table.Carefully evaluate which ones are needed:

• From a usability point of view• From a harmonization point of view (import manager)

Display fields are used to identify the record to the user, but they are also used bythe system. For example, the display fields are concatenated to identify a record(besides the technical key, hidden from the user) in the A2i_CM_History table. Ifthis concatenated string exceeds the length of the data field, information gets lost!



Figure 83: Best Practices – Qualified Tables 1

Figure 84: Best Practices – Qualified Tables 2

Try to find a limited and more or less static set of data for the non qualifiers.Do not use flexible values, like dates, to be non qualifiers, as long as they arenot linked directly to the sub-object and are not dependent on the qualified linkbetween the main object and the sub-object.

Use qualifiers for all information, which is dependent on the lifetime of thequalified link in order to keep the list of records in the qualified table as small aspossible



Restriction: You can only build a qualified look up from the main table to aqualified table.

Attention: The qualified links are ordered automatically by the system. Keep thisin mind for scenarios, where the order of the qualified links is important! Forinstance with integration to ERP IS-H (Industry solution for hospitals): ingredientsfor medical materials.

Attention:If you need to represent a deeply-structured data model on MDM (morethan two levels; check IDOC structures and ERP data models for explanation)and use qualified tables to build this, you need to control the context during thedistribution from the Syndicator. The Syndicator cannot do this. This needs tobe done on XI or in the remote inbound processing!

Figure 85: Best Practices – Relationships

If relationships are used during data modeling, keep in mind that they cannot bedistributed via the MDM Syndicator.

Relationships for main table objects can also be built using qualified tables or flattables. This work-around is fine for usability and distribution, but needs to becontrolled either from system side (not always in the standard, MDM workflowcannot support all scenarios) or by means of an organizational procedure. Thisalso has a negative impact on performance.



Figure 86: Best Practices – Key Mapping

Use key mapping as much as necessary and limit its usage as much as possible!

The usage of key mapping might have a negative impact on performance(especially during the syndication process) if used in an excessive way.

Carefully evaluate where key mapping is to be used. This includes the main tableas well as all subtables that are relevant for the distribution.

Key mapping should only be used to represent the keys of local instances in thecontext of a global instance for semantically same master data objects in the systemlandscape. For instance, do not use it to reflect any kind of history of an object!



Figure 87: Best Practices – Hierarchies

Records can only be distributed in a flat structure from a standard hierarchy table.

Records from a hierarchy table including their hierarchy path can only be exportedin the context of another object with a lookup relation to the hierarchy table.

A work-around can be built based on that to distribute hierarchies, but this is notautomatically controlled by the system and might lead to inconsistencies overtime. A control mechanism need to be established!

Figure 88: Best Practices – Look Ups - Check Tables



Consider carefully the usage of check tables in MDM, because every check tablecauses a memory overhead compared to a free form field, if it is not used in acorrect way.

The number of check tables is performance-relevant, such as the loading timeof the repository.

Check tables also need to have a governance model applied to them and, if relevantfor distribution, need to be maintained and synchronized with the remote systems.

A foreign key relation to a check table in a remote system does not always implythe use of a check table on MDM, but gives a good hint to evaluate its use.

Use check tables in order to represent valid value lists to the user to control theinput. Do not misuse the lookup tables just to provide a search tab to the user. Tryto keep the amount of records in the check tables to a necessary minimum.

Data Governance: The ownership for the check tables, if relevant for thedistribution, is outside of MDM most of time. Therefore the requirements of theremote systems need to considered, especially if key mapping is needed.

Figure 89: Best Practices – Tuples

Sharing tuple subrecords: Typically, each child tuple subrecord is private to thesingle parent record that owns it. However, if you want to be able to referenceeach tuple subrecord from multiple parent records, you must explicitly store thetuple subrecords as records in an actual table, and then reference them from therecords of the parent table.



Tuples are a generalized form of custom composite data types, and that tuples canbe used to model various “exotic” data structures, such as flexible hierarchiesand networks. When using tuples to model these data types and structures,however, consider that tuples can model only their data storage aspects but notnecessarily their specialized semantics and associated functionality. For example,a measurement is more than just a composite data type comprised of a numericvalue and a unit of measure. In fact, it features built-in support for varioussemantics, including dimension-specific pick lists of units, unit conversion,sorting across units, unit synonyms, and parsing of inbound string values (e.g.“3 inches”). Similarly, hierarchical structures modeled using tuples require alayer of additional semantics that allow you to conveniently materialize, navigate,manipulate, import, and export the hierarchy.

In essence, tuples are just a way to access the pure relational aspects of a relationalDBMS, with the added ability to reuse the definition so that the tuple can be usedin multiple tables across a data model. And just as a relational DBMS:

1. does not provide semantics around the relationships it defines, neither dotuples

and

2. cannot always model data efficiently (and hence the need for other types ofdatabases), so too tuples are not always going to be efficient (and hencethere is a need for other native types).

Tuples applied to attributes within a taxonomy provide a little twist. For example,consider a shirt available in a total of 18 (2 x 3 x 3) variations: 2 styles (Crew andV-Neck); 3 colors (White, Black, and Gray); and 3 sizes (Small, Medium, Large).Using three attributes (Style, Color, and Size), making each one multi-valued, andputting each set of multi-values into each attribute would conveniently representall the variations by expressing all the combinations of the individual values.

... Style Color Size

Crew; V-Neck White; Black;Gray

Small; Medium;Large

However if some combinations are not valid (e.g. Gray available only inMedium), or you need to store other information with each value combination,then independent multi-valued attributes are inadequate. Tuples can be used toremedy this limitation. You can replace the three individual attributes with athree-attribute tuple, where each value combination (e.g. Crew, White, Small)represents an individual product variation, and all the product variations can stillbe stored within a single product record.



... Variant

Style Color Size

Crew White Small

Crew White Medium

Crew White Large

Crew Black Small

.. ... ...

V-Neck Gray Medium

V-Neck White Small

... ... ...

Combining tuples and multi-values provides an efficient way to represent anyirregular subset of all the combinations of values. Attribute tuples are not yetsupported by MDM, nor are a rich-enough set of attribute data types. However,you can simulate product variations by promoting the relevant variation-inducingattributes to a field tuple in the product record.

Figure 90: Best Practices – Lookup Main

MDM features a new data entry control for entering data into a Lookup [Main]field. Because lookup tables may contain hundreds of thousands of records (ormore), selecting one or two lookup values from among all of the possible valueswould be like looking for needles in a haystack. MDM instead provides a morepractical solution: using the mini-search control. Mini-search is the only wayto edit Lookup [Main] fields. With mini-search, instead of browsing through



a pick list to select a specific value for a lookup field, you directly enter thespecific value in a drop down search control, and Data Manager then shows youhow many matching records are found in the lookup table. You can performlimiting searches on each display field in the lookup table by selecting values forlookup display fields or typing in exact values for text fields. If you enter enoughsearch criteria for Data Manager to find a single exact match, Data Managerautomatically populates the lookup field with this value. Challenges arise whenmultiple matching records are found, and/or the lookup field is multi-valued. Inthe case of multiple matches, you must select which matching record to use as thelookup field’s value. In the case of multi-valued lookup fields, you must be able toview collectively (yet edit individually) the values you want to include in the field.MDM helps you overcome these challenges in the following ways:

• Multiple search results. The pop-up Select Lookup Record dialog lets youchoose which record to use as the lookup field’s value.

• Multi-valued lookup field. The pop-up Edit Lookup Values dialog lets youview and edit the set of values for the lookup field.

Figure 91: Best Practices – Data Consistency

If you, for instance, want to validate, whether an entered Street/City/ZIP-Codecombination is valid, then this is typically done by a third party product, which iscalled by a web service or linked to MDM by the Enrichment Controller.



However, if you would like to do this on your own, then you should store thisinformation in a non-lookup table, which is called from your application. MDMrepositories are performance optimized for main table access. Reading largevolumes of data from lookup tables causes performance problems. Lookup tablesshould always have only a limited number of records.

Solution in such a case would be to

• Either define a second repository where all these value combinations arestored in the main table and this repository would be accessed for validation.If a custom user interface is developed, than this can be considered in theprogram coding. If data maintenance using the Data Manager is planned,then it would be required to have two Data Manager sessions open at thesame time..

• Store this information in a normal database table, which is accessed by aprogram.

Data consistency needs to be controlled and ensured by the master data processes,but should be supported by the data model as much as possible.

If the control on the MDM side cannot cover the full distribution, leveragethe functionalities of other NetWeaver components to support the distribution.For instance, representation of deep structures in the MDM data model canbe controlled by user interfaces and validations. The distribution needs to becontrolled by XI to ensure the correct context.

Consider the needed authorizations during modeling, to control and support thedata governance model on MDM.

Guide users through the maintenance process by using workflows.

For every field in the solution data model (not only MDM) there should be a singlepoint of access to create and maintain to the extent practical.

Figure 92: Carefully Investigate the Use of Work-Arounds

Some work arounds are unavoidable. For instance, attributes do not have the sameproperty “Required” as do fields. So Branch Validations provide the mechanism toensure that certain attributes are populated.



Figure 93: Additional Considerations for Data Modeling

Calculated field values appear as read-only on the Record Details tab. Theirread-only values are determined by the expression entered for the field in theMDM Console. MDM automatically updates calculated field values wheneverchanges are made to main table fields or qualified table fields via the Data Manageror through import. However, calculations based on lookup field values are notupdated automatically after fields on the lookup table are modified. In these cases,the calculated field must either be updated manually from the Records pane or elsethe entire repository must be unloaded and then reloaded with the Build Indicesoption. To manually update the values of a record’s calculated fields, simplyright-click on the record in the Records pane and choose Recalculate from thecontext menu. All calculated field values in the selected records will be updatedby this operation.



Exercise 4: MDM Data Modeling BestPractices

Exercise ObjectivesAfter completing this exercise, you will be able to:• Give recommendation on how to model a repository in regards to

maintenance and performance aspects.

Business ExampleYour former customer “MegaSHIP” – a US-wide delivery service – called you tosupport them with their MDM implementation.

They would like to do CMDM with a custom defined model for vendor records.For the first project phase they would like to connect one SAP ERP system, lateron in a second phase 5 more systems (one mySAP CRM, SAP NetWeaver BI andthree legacy systems).

The creation of new records is done mostly via a customer developed Web-UI. Ifa new vendor record is to be created in the WEB UI, the application performs ahome-grown check algorithm to validate the address data (e.g. Street, Street-Nrhas the right ZIP-Code) and in case of a success, stores the vendor record inMDM. Newly created and updated records are periodically syndicated into thesatellite systems. In exceptional cases a Master Data Administrator can createrecords also by using the Master Data Manager.

The project is facing currently severe performance problems during the Initialload of the vendor records into the MDM system. The start of testing and the golive dates are in high danger.

To also facilitate paying vendor invoices electronically, MegaSHIP wants toinclude bank details for vendors and they are not sure that this has been set upproperly. The customer suspects that this might be a cause for the performanceissues.

You were recommended as one of the top experts for Data modeling and thereforeit’s your task to analyze the Data Model and come up either with recommendationsfor improving the Data Model or to give a confirmation, that the reason for theperformance problems must be somewhere else, e.g network bandwidth, EAItool, etc.

Since the data is highly confidential, and you’re not yet on-site, MegaSHIP sentyou via e-mail a small subset of data from their Philadelphia vendor’s base.



Task:MDM Server has been mounted and started.

1. Unarchive the delivered repository MDM400_Vendor asMDM400_Vendor_#, where # is your Group letter, and perform an analysisof repository structure and data and give recommendations to the customer.Write these recommendations on paper.



Solution 4: MDM Data Modeling BestPracticesTask:MDM Server has been mounted and started.

1. Unarchive the delivered repository MDM400_Vendor asMDM400_Vendor_#, where # is your Group letter, and perform an analysisof repository structure and data and give recommendations to the customer.Write these recommendations on paper.

a) Banks Table

1. The field Country which is a Lookup [Flat] field is marked as adisplay field.

2. The field Country which is a Lookup [Flat] field is marked asthe primary display field.

3. The field Bank Key should be the primary display field, not thethird display field.

4. The table is linked to the Vendors table only through theassignment of the Bank Details tuple which refers to the Banksmain table. This seems like an oblique reference rather than adirect one.

5. In the table many fields are defined as a sorted field. Sort onlythese fields which you really need to be sorted.

6. In the many fields are enabled for keyword search. Enable onlycritical fields for keyword search. The less keyword enabledfields the better.

7. The tuple Bank Details might be used in place of the many fields.There is duplication here.

b) Vendors Table

1. Many Lookup [Flat] fields in the table are linked to the Yes/NoFlat Table. Each of these fields should substitute a field of typeBoolean.

2. The Vendor ID field does not have the property Unique selected.3. The tuples assigned to the table are duplicated, since the complex

tuple already includes the other assigned simple tuples. Thecomplex tuple should be unassigned and then eliminated.

4. In the table many fields are defined as a sorted field. Sort onlythese fields which you really need to be sorted.




5. In the many fields are enabled for keyword search. Enable onlycritical fields for keyword search. The less keyword enabledfields the better.

6. There are validations for VAT number checking, but they do notwork. The records in the repository have no VAT numbers, yet thevalidation does not respond with an error because these validationshave the value None for the property “Automatic Execution”.Perhaps this should be set to either aWarning or an Error.

7. The only validation which works, Sample Mandatory FieldCheck, is checking the field Search Term 1, which is not markedas Required.

c) Both Main Tables

Neither of the main tables have key mapping enabled. Whensyndicating to client systems, key mapping should be enabled so that,for instance, future updates on the MDM Server can also update theright record in the client systems.

d) Repository

1. There are no remote systems designated to facilitate key mapping.2. Too many languages are enabled. Delete unnecessary languages

and add them back when the are needed.3. Too many flat lookup tables have key mapping enabled.4. The workflowMDM_Syndication has only a syndication step

which has no outbound port assigned. It will not work.5. The workflowMDM_Syndication has only a manual trigger.

How is this useful? Why not use the Syndicator instead?6. The workflowMDM_Vendor_ Match has only a match step and

is assigned to the users, [Owner} and Admin, concurrently. Thisdoes not make sense.

7. The workflowMDM_Vendor_ Match has two triggers, RecordImport and Manual. Yet the Autolaunch property is set toThreshold. The Autolaunch property works only with the triggersRecord Add and Record Update.

8. There are no validations for the Banks main table.

e) Fax Number Tuple

The field Country is the primary display field instead of CompleteNumber.

f) The repository contains no validations to check, whether at leastsome fields are populated. As a consequence it’s possible to createcompletely empty records in the repository.



Lesson Summary

You should now be able to:• Learn best practices before starting the definition of a Data Model



Lesson: MDM Data Modeling Issues and Solutions

Lesson OverviewThis lesson tackles some issues which arise during the process of designing thedata model of a repository and suggests how they might be handled.


• List the various tips to solve specific problems that usually occur in manyprojects

• Explain how to avoid pitfalls that might cause problems at a later point intime

Business ExampleYour company is implementing MDM. You plan to implement several object typesin parallel. During the design phase, it turns out, that similar problems come upacross various different object types, e.g.

• Can a repository be both a system of record and a system of reference?• What to do about time dependency?• How to handle the syndication of Relationships?• What about the sharing of attributes between categories?

Common Data Modeling Issues and ProposedSolutions

Figure 94: Single Repository = System of Record and Reference?


MDM400 Lesson: MDM Data Modeling Issues and Solutions

This issue also arises with reference data (control data) like countries, currencies,plants, company codes, etc., which is loaded into the repository from a remotesystem. Is the intent to maintain the reference data records in MDM once theyhave been loaded into the repository? If this is not the case, then these recordsare maintained in the remote system and MDM is using them as a System ofReference. Of course, reference data is normally quite small in comparison to themain table(s) of a repository, so there is no issue in storage. The key to combininga company's own data with data provided by an outside entity (supplier) isto provide a way to quickly distinguish them and prevent them from beingmaintained in the repository through the Data Manager. Loading updates to thisexternal data stored in the main table is easy enough using the filtering functionsin the Record Matching step in the Import Manager.

In the Import Manager Record Matching step, Record filtering expands theconcept of import by complementing the source-centric set of import recordswith a destination-centric set of records that includes not only matched recordsbut also unmatched records in the filtered destination set. Specifically, it allowsyou to specify basic search criteria to filter the source and destination records inconjunction with various operations within MDM Import Manager and MDIS, andwhen performing the import itself. Filtering narrows down both the source anddestination record sets, but with slightly different effects, as follows:

• Source. Narrows down the set of source records so that those that do not meetthe filtering criteria can be excluded from the import. The filter is exclusive,and source records that do not meet the filtering criteria are deemed invalid.

• Destination. Narrows down the set of destination records, excluding thosethat do not meet the filtering criteria from record matching. The filter isinclusive, and expands the set of records on which you can perform importoperations to those that do meet the filtering criteria.

Typically, the MDM Import Manager is used to perform a “net change”synchronization, in which a file of source records is imported to update andreplace matching destination records and create new ones, leaving untouchedthose destination records that do not match source records. Consider, by contrast,a “full refresh” requirement, in which a file of source records must be importedand should update and replace a corresponding set of destination records in itsentirety, whether or not every destination record matches a source record. Inparticular, source records that meet the filtering criteria but do not exist should becreated, those that meet the filtering criteria but do exist should be used to updateor replace existing destination records, and those that do not meet the filteringcriteria should be ignored. Similarly, destination records that meet the filteringcriteria and match source records should be updated or replaced, and those thatmeet the filtering criteria but do not match source records should be deleted. Ineffect, all existing destination records that meet the filtering criteria must beaffected by the import, not just those matching source records.



Figure 95: Relationships with Time Dependency

Relationship records consist of a predefined set of fields and are user-created inMDM Console. Each record defines a particular product-level relationship, chosenfrom among several different basic structural relationship types. Each type ofrelationship (e.g. parent/child) corresponds to a real-world product relationship(e.g. assemblies and components). For each relationship defined in MDMConsole, you specify the related products and/or non-products for each main tableproduct in Record mode within the MDM Client.

In practice, an MDM repository can often represent the same subtable informationusing a qualified table, a parent/child product relationship or a tuple, each withslightly different effect; choosing the right structure depends on how you intend tosearch the MDM repository. For example, if: (1) the subtable records have one ormore lookups fields; (2) a portion of the subtable records consists of values that areshared by the main table records while another portion consists of values that aredifferent for each main table / subtable record link; or (3) you want MDM to limitmain table product records using drill-down search against the subtable records,then use a qualified table (which reduces the number of subtable records throughthe use of qualifiers). Alternatively, if the number of subtable records is very large(larger than the number of main table records), and full validation against all of thesubtable record values is important, then use a parent/child product relationship.

MDM tuples allow you to model flexible hierarchies and networks, complementinghierarchy lookups and tables with generalized support for hierarchical main tableentities. Specifically, by including one or more lookups into the same or anothertable among the fields of a tuple, you can express composite and arbitrarilycomplex relationships between similar and dissimilar business entities and alsoattach link-specific “qualified” information to every set of related records.

If time dependency of product relationships is required, the above businesscase can be solved by using a qualified lookup table to store the relationshipinformation with additional time-based fields as qualifiers.



Figure 96: Taxonomy Attributes Reuse 1

Multi-valued attributes make the structure of an MDM repository dramaticallysimpler, more compact, and more searchable, by allowing you to store allthe values corresponding to a particular data element in the same place. Thealternative is having to create multiple attributes, in some cases up to a maximumof one attribute for each possible value.

Figure 97: Taxonomy Attributes Reuse 2

In MDM, attributes are associated with – linked to – categories. Categories in thetree that have attributes directly linked to them are highlighted in bold. Similarly,attributes that are linked to the selected category in the tree are displayed in theAttributes pane with a “linked” icon in the Linked column of the grid.

By promoting an attribute shared across categories to a super-class orsuper-category, the child categories belonging to that node then “inherit” theattribute.

Inherited attributes are visible if the linked icon is gray and has a superscriptnumber next to it. This indicates that the attribute is not linked directly to theselected category but rather to one of its ancestors in the tree; the number indicates



the level of inheritance. For example, “1” means that the attribute is inheritedfrom one level up; that is, it is linked to the parent of the selected category. A “2”superscript means that the attribute is inherited from two levels up, and so on.

If you sort the Attributes pane by the Linked column, the attributes will alwaysbe listed with the linked and inherited attributes at the top of the list; in effect,they will always float to the top as you move from category to category in thetaxonomy tree.

To set the Attributes pane to display only those attributes that are linked to orinherited by the selected node in the taxonomy tree, choose Attributes → LinkedAttributes Only from the main menu. This command is a toggle; to restore thedisplay of all attributes to the grid, choose the Linked Attributes Only commandagain.



Lesson Summary

You should now be able to:• List the various tips to solve specific problems that usually occur in many


time


Unit Summary MDM400

Unit SummaryYou should now be able to:• Explain how MDM data modeling differs from traditional data modeling

approaches• Perform the appropriate steps to define a MDM data model• Explain how to differentiate a well-defined data model from a data model

with limitations• Learn best practices before starting the definition of a Data Model• List the various tips to solve specific problems that usually occur in many


time


Unit 4MDM Data Modeling Implementation

Approach

Unit OverviewBig Retail, a large sales company has been struggling with their own processes andmaster data, is in the process of acquiring a regional sales company, Selly. Duringthis acquisition, Big Retail plans to implement MDM. To refine your experiencewith the MDM Data Modeling approach, you were tasked to develop a data modelfor materials based not only on Big Retail's ERD, but on their requirementsconcerning the consolidation of their master data with that of their new acquisition.


• Explain the milestones and challenges of an SAP MDM implementationproject

• Describe the non-technical considerations related to an SAP MDMimplementation

• Design a thoughtful blueprint for an implementation project based on thesimulator experience

Unit ContentsLesson: MDM Data Modeling Implementation Approach Case Study ...138

Exercise 5: MDM Data Modeling Implementation Approach ... . . . . . .145


Unit 4: MDM Data Modeling Implementation Approach MDM400

Lesson: MDM Data Modeling Implementation ApproachCase Study

Lesson OverviewThis lesson serves as an introduction to a extended case study in which thestudents will apply their knowledge of MDM data modeling steps together withbest practices to review the entity relationship diagram (ERD) for a large salescompany, Big Retail, who has struggled with their processes and master data.They are acquiring a regional sales company, Selly, and see this acquisition as anopportunity to design a data and governance model which will not only aid theconsolidation of their master data and that of the acquisition, but also addresstheir process issues.


• Explain the milestones and challenges of an SAP MDM implementationproject

• Describe the non-technical considerations related to an SAP MDMimplementation

• Design a thoughtful blueprint for an implementation project based on thesimulator experience

Business ExampleYou have been contracted to design, lead, or implement a master data managementinitiative using SAP MDM.

Data Modeling Implementation Case Study

Figure 98: MDM Data Model Case Study – Project Milestones


MDM400 Lesson: MDM Data Modeling Implementation Approach Case Study

Figure 99: Understand the Business Case

BigRetail needs your company's assistance in planning for a recent acquisition,Selly. BigRetail is looking at the same time to upgrade their landscape forfuture enhancements that it is planning for. BigRetail (a global retailer) has200,000 customers that actively purchase 150,000 different products from them.The average number of sales orders per week is between 400 and 1000. Theyare currently using R/3 Sales and Distribution and Supply Chain to track thisinformation.

Selly (a Southern California retailer) has 5,000 customers that actively purchase50,000 different products from them. The average number of sales orders perweek is between 50 and 100. They are currently using a home- built softwaresystem to track this information.

Following a review of their business practices, BigRetail discovered many flawsin the way they manage their information:

• they found data quality issues such as duplicate or incomplete records whichresulted from a lack of proper governance processes for the information.

• the quality of their product data reflected on the quality of their transactionaldata and the firm's overall performance revealing that distribution and supply& demand management were not optimal where reports did not give a truepicture of their status.

When the deal to merge with Selly came through, a decision was made thatthe data consolidation processes needed for the merger will be accompanied byan overhaul in the way they manage their master data. The new master datamanagement system needs to formalize governance processes around the data,simplify search and access while improving visibility of the data by management.



Figure 100: Define Project Parameters

BigRetail did not want to miss out on the opportunity to cross-sell newly acquiredSelly products. They have also discovered that the lack of automation in productinformation exchange was resulting in repeated and tedious data-related tasks.Both BigRetail and Selly are active in promoting their products, but now thechallenge is to send consistent information to all consumers.

The supply chain group has been working hard to keep costs down, but recentlyhas seen a spike in returns due to inaccurate product information. Errors in sizeand weight information have also lead to non-optimal freight loads and higherinbound and outbound shipping charges. These errors have been attributed todelays in receiving, handling, and slotting in the warehouses. The longer the delaythe higher the buffer stock that is required.

Lastly, customers have stated very clearly that they would like to see a moreaccessible search mechanism on the online order website. Currently, a customer,once logging in, can only search by product number or by a fuzzy name search.Many times the search result is none. There is no capability to search by producttype, description, or price.



General requirements:

• Access to all product information from one source.• Master data will be accessible by 2 groups: Sales/Marketing and Supply

Chain. However, the Sales group has a requirement to see the data organizedby type of item while the Supply Chain group wants items to be groupedtheir way.

• All data entered must go through a validation process to eliminate typingerrors and incorrect assignments.

• Also additional validation which is approved by the Directors is requiredwhen adding or modifying a region or a branch.

• Easy search for products according to various parameters.• There are two systems that require the final record information. These

systems will accept a flat file.• Before incorporating Selly's data, this information needs to be compared to

BigRetail's data so that redundant information is removed.• The input and output of data should be automated to the highest degree

possible.

General questions to be asked of the customer:

• Does it make sense to start an MDM implementation?• What would the business gain beside consolidation of products from the

merging companies? (e.g. formalizing/creating master data managementprocesses, improved data quality, etc)

• What otherf questions do we want to ask the customer now?

Figure 101: Review ERD and Data Sets

Look at the ERD and translate the model into an MDM repository.



Figure 102: Create and Design Repository 1

Remember the modeling best practices from previous units.

Figure 103: Create and Design Repository 2

One major requirement from Big Retail is high data quality, due to past problems,so what MDM data governance tools should be employed to satisfy this demand?Remember that good design and solid data governance go hand in hand.

Figure 104: Design Data Quality and Governance



MDM offers multiple layers of data management capabilities for maintaining dataintegrity, enforcing business logic, and automating business processes, as follows:

• Data integrity. At the core layer, MDM offers flexible schema managementand an abstract object model that enforces data integrity with a varietyof innovative features, including pick lists, enumerated text attributes,measurement data types, and so on.

• Validations. Layered upon data integrity, MDM validations are Excel-likeexpressions that allow you to enforce rules and business logic by definingtests for a variety of conditions, and then to execute a validation or validationgroup against one or more records.

• Workflows. At the outer layer, MDM workflows consist of a sequence ofsteps that allow you to orchestrate a series of operations that include usertasks, validations, and approvals, automating business processes at the datamanagement level.

These three concentric layers of data management around a core of MDM dataare illustrated below:

Figure 105: Three Layers of Data Management

Remember also that workflow dovetails with the MDM check out mechanism,allowing a workflow to proceed to completion on a private, hidden copy of therecords of the job.



Exercise 5: MDM Data ModelingImplementation Approach

Exercise ObjectivesAfter completing this exercise, you will be able to:• Explain the milestones and challenges of an SAP MDM implementation

project• Describe the non-technical considerations related to an SAP MDM

implementation

Business ExampleBIGRETAIL needs your company’s assistance in planning for a recent acquisition,SELLY. BIGRETAIL is looking at the same time to upgrade their landscape forfuture enhancements that it is planning for. BIGRETAIL (a global retailer) has200,000 customers that actively purchase 150,000 different products from them.The average number of sales orders per week is between 400 and 1000. Theyare currently using R/3 Sales and Distribution and Supply Chain to track thisinformation.

SELLY (a southern California retailer) has 5,000 customers that actively purchase50,000 different products from them. The average number of sales orders perweek is between 50 and 100. They are currently using home built software systemto track this information.

Following a review of their business practices BIGRETAIL discovered many flawsin the way they manage their information -- they found data quality issues such asduplicate or incomplete records which resulted from a lack of proper governanceprocesses for the information. The quality of their product data reflected on thequality of their transactional data and the firm's overall performance -- distributionand supply & demand management were not optimal, reports did not give a truepicture of their status. When the deal to merge SELLY came through a decisionwas made that the data consolidation processes needed for the merger will beaccompanied by an overhaul in the way they manage their master data. Thenew master data management system needs to formalize governance processesaround the data, simplify search and access while improving visibility of the databy management.

BIGRETAIL did not want to miss out on the opportunity to cross-sell newlyacquired SELLY products. They have also discovered that the lack of automationin product information exchange was resulting in repeated and tedious data relatedtasks. Both BIGRETAIL and SELLY are active in promoting their products, butnow the challenge is to send consistent information to all consumers.



The supply chain group has been working hard to keep costs down, but recentlyhas seen a spike in returns due to inaccurate product information. Errors in sizeand weight information have also lead to non-optimal freight loads and higherinbound and outbound shipping charges. These errors have been attributed todelays in receiving, handling, and slotting in the warehouses. The longer the delaythe higher the buffer stock that is required.

Lastly, customers have stated very clearly that they would like to see a moreaccessible search mechanism on the online order website. Currently, a customer,once logging in, can only search by product number or by a fuzzy name search.Many times the search result is none. There is no capability to search by producttype, description, or price.

Task 1:Review Business Requirements & Planning

Review the business requirements and answer the following questions

1. Will a master data management project answer the business requirements?

2. Who should sponsor the project?

3. Which roles in the company should be involved and why?

Task 2: Review ERD DiagramReview the ERD diagram, ERD.doc. Dismiss any irrelevant information andanalyze how the data can be modeled in an MDM repository. Answer thequestions that follow.

1. Review the ERD diagram, ERD.vsd.

Your instructor will guide you to find this diagram on the MDM Shareddrive, Folder MDM400_92.

This is a description given by the client of how the data model should look atthe end of the process.

Dismiss any irrelevant information and analyze how the data can be modeledin an MDM repository (what’s the main table? which table types to use?)




Figure 106: ERD Diagram

2. Which master data object should be the focus? Why?

3. Will this be the main table? Why?

4. Is there any irrelevant information in the client’s proposed data model?

5. Will more than one main table help ease the client’s concerns?

6. Is there provision for a taxonomy?

7. If there is a taxonomy, how do you propose to handle the “Dimensions”and “Weights?”

8. Does the “Prices” part of the data model fit appropriately? How should youhandle in an MDM repository?

Task 3: Examine Sample DataExamine Sample Data provided.

1. Examine Sample Data provided in the following files. Your instructor willguide you to find these files in the MDM Shared drive, Folder MDM400_92.

Big Retail.xls

Divisions.xls

Selly.mdb




UNSPSC_IT_Only.mdb

Task 4: Repository DesignBuild your repository based on your planning and analysis.

1. Use the MDM400_STAGE0.a2a repository archive as the basis of yourrepository.

2. Add the required Tables, Fields and Remote Systems to your repository.



Solution 5: MDM Data ModelingImplementation ApproachTask 1:Review Business Requirements & Planning

Review the business requirements and answer the following questions

1. Will a master data management project answer the business requirements?

a) Yes, a master data management project will definitely answer theclient’s business requirements basically for two reasons: one, Big Retailis already having significant issues with the master data concerningtheir own products and an overhaul is called for; and two, Big Retail,must incorporate Selly’s products as well to not only identify duplicatematerials, but to apply the same standards of data quality and datagovernance on all the data Big Retail owns.

2. Who should sponsor the project?

a) Projects of this scope should always be sponsored by the most seniormanagement, in this case, the individuals in charge of Big Retail’sSupply Chain and Sales, so that differing requirements will beimplemented.

3. Which roles in the company should be involved and why?

a) Role in the company which should be involved include: Sales OrderAdministration, Product Management, Materials Management, Sales,and both Accounts Receivable, Accounts Payable and IT. Both thebusiness and technical sides of the business need to be represented inorder to ensure a smooth transition.

Task 2: Review ERD DiagramReview the ERD diagram, ERD.doc. Dismiss any irrelevant information andanalyze how the data can be modeled in an MDM repository. Answer thequestions that follow.

1. Review the ERD diagram, ERD.vsd.

Your instructor will guide you to find this diagram on the MDM Shareddrive, Folder MDM400_92.

This is a description given by the client of how the data model should look atthe end of the process.

Dismiss any irrelevant information and analyze how the data can be modeledin an MDM repository (what’s the main table? which table types to use?)




Figure 107: ERD Diagram

a)

Figure 108: ERD Diagram Proposed Solution

2. Which master data object should be the focus? Why?

a) The master data object focus should be Products because all of theproblems experienced by Big Retail and the proposed future of BigRetail’s sales and supply chain revolve around Products

3. Will this be the main table? Why?

a) Products will be a main table in the new MDM repository, since themain table of a repository always involves the master data object offocus.




4. Is there any irrelevant information in the client’s proposed data model?

a) Can any parts be eliminated? Why?

The part about “Locations_Stock” should be questioned. Is the intenthere to describe where product is located as the source for sales ordersand the storage location of goods receipts? Or is the intent an attemptat bringing into the repository what current stock on hand is availableat any given time? If it is the latter, then this is irrelevant, since this isactually transaction data, which has no place in a master data repository.If the true intent is the former, then it is worthy of consideration.However, if that is the case, then why do we also identify product bythe “Warehouses” portion of the proposal? This would be redundantand one could be eliminated. If the “Locations_Stock” is retained andthe “Warehouses” part is removed, then the section on “Employees”comes into question.

b) What should you do with the part concerning Purchased Products?

Again it is matter of intent. Is the intent to describe which productshave been purchased by customers through their sales orders? Or isthe intent a way of describing material listings, where this describesthe products which can only be purchased by certain customers? If itis the latter, then this might be an appropriate component of a MDMrepository. If is the former, then this is transactional data and has noplace in a master data repository. From the proposed data model, itseems that the former is what is intended, but you could point out to theclient that the latter intent might be desirable.

c) If the client insists on having it in their data model, perhaps, for futuremarketing purposes, is there any other way to interpret this data?

If Purchased Products is interpreted as a way of describing limitationsas to what a customer can purchase and consequently determine whichproducts are purchasable by the most customers, then this block ofdata will have to be re-interpreted. This could be accomplished bycreating a second main table for customers and then having each ofthe two main tables, Products and Customers, refer to each other withLookup [Main] fields.

d) Would an additional main table for “Employees” help the design ofthe data model?

Employees seems to be irrelevant data for the intended purpose of therepository regardless of whether “Locations_Stock” or “Warehouses” isretained. While a third main table is permissible, it would unnecessarilycomplicate the design and detract from the overall purpose of therepository.




5. Will more than one main table help ease the client’s concerns?

a) Yes, since the client definitely wants to know that only certain productsare purchasable by a customer and which products could be purchasedby how many customers. The client wants to use this information forProduct Management purposes.

6. Is there provision for a taxonomy?

a) The entire sections denoted by “*_Properties” lends itself to theimplementation of a taxonomy. What could be questioned herefor clarification purposes is whether this is a Big Retail-specificclassification or will Big Retail utilize a standard classification scheme,like UNSPSC or e-Class.

7. If there is a taxonomy, how do you propose to handle the “Dimensions”and “Weights?”

a) Since these are linked to each section denoted by “*_Properties,”“Dimensions” and “Units” will become specific attributes shared bythe entire classification scheme.

8. Does the “Prices” part of the data model fit appropriately? How should youhandle in an MDM repository?

a) Is the intent here to model the price which a customer pays at thetime of purchase? Or is the intent here to model the standard price ofa product regardless of customer or condition? If is the latter, thenhandling this as a qualified flat lookup table would be most appropriatesince each product could have various prices based on country and/orcurrency. If is the former, then this is actually transactional data anddoes not have a place in a master data repository. The client actuallyintends this to be product pricing regardless of customer or conditionwith the exception of country and/or currency.

Task 3: Examine Sample DataExamine Sample Data provided.

1. Examine Sample Data provided in the following files. Your instructor willguide you to find these files in the MDM Shared drive, Folder MDM400_92.

Big Retail.xls

Divisions.xls

Selly.mdb

UNSPSC_IT_Only.mdb

a) Review each file.




Task 4: Repository DesignBuild your repository based on your planning and analysis.

1. Use the MDM400_STAGE0.a2a repository archive as the basis of yourrepository.

a) In the Console, right click on your MDM Server, “localhost,” to choosethe option, “Unarchive Repository.” Enter user id dba and password= training.

b) Use the bottom drop down box, to choose the archive file.Give thenew repository the name “MDM400_DataModel_#,” where # is yourgroup number.

c) Click the OK button. When you get a message saying your repositoryhas been successfully unarchived, click “No” to not see the detailed log.

d) Your repository will be locked. Right click on it to choose the option“Connect to Repository” with user = Admin and password = (blank).

2. Add the required Tables, Fields and Remote Systems to your repository.

a) A proposed solution might look like this:

Figure 109: Big Retail: A Proposed Solution

b) Add the following tables:

Manufacturers Main

Divisions Flat

GTIN Types Flat




GTIN Tuple

Prices Tuple

Product Manufacturer Tuple

Address Tuple

Currencies Flat

Product Hierarchy Hierarchy

c) Add the following fields to the tables:

Manufacturer Address Tuple

VAT RegistrationNumber

Text (20)

DUNS Number Text (20)

Address Street Number Text (12)

Street Name Text (50)

Postal Code Text (12)

City Text (5)

Country Lookup [Flat]

Currencies ISO Code Text (10)

Prices Currency Code Lookup [Flat]

Price Currency

ProductManufacturers

Manufacturer PartNumber

Rename from“Name”

Country ofManufacture

Lookup [Flat]

Manufacturer Lookup [Main]

Model Number Text (25)

Manufacturer SerialNumber

Text (25)

GTIN GTIN Rename from“Name”

GTIN Type Lookup [Flat]

UOM Lookup [Flat]

Main GTIN Text (50)




Products GTIN Tuple (multi-value)

ProductManufacturer Tuple (multi-value)

Product Price Tuple (multi-value)

Manufacturer Lookup [Main]

Division Lookup [Flat}

Attributes Speed Numeric

CPU Type Text

Hard Disk Numeric

Operating System Text

Optical Device Text

RAM Numeric

Screen Resolution Numeric

Screen Size Text

Dot Pitch Numeric

Frequency Numeric

Horizontal Frequency Numeric

Manufacturer Text

Price Class Text

Gross Weight Numeric

Net Weight Numeric

Length Numeric

Height Numeric

Width Numeric

Modem Speed Numeric

Response Type MS Numeric

d) Add Remote Systems.

Big Retail inbound/outbound

Selly inbound/outbound



Lesson Summary

You should now be able to:• Explain the milestones and challenges of an SAP MDM implementation


implementation• Design a thoughtful blueprint for an implementation project based on the

simulator experience


Unit Summary MDM400

Unit SummaryYou should now be able to:• Explain the milestones and challenges of an SAP MDM implementation


implementation• Design a thoughtful blueprint for an implementation project based on the

simulator experience


MDM400 Course Summary

Course SummaryYou should now be able to:

• Describe the principles of data modeling and data quality pertaining to MDM• Demonstrate the application of the principles of data modeling and data

quality to MDM repositories


Course Summary MDM400


FeedbackSAP AG has made every effort in the preparation of this course to ensure theaccuracy and completeness of the materials. If you have any corrections orsuggestions for improvement, please record them in the appropriate place in thecourse evaluation.
