unit_03_ppt_for xml

© SAP AG MDM400 3 - 1

© SAP AG 2007

Contents:

Steps required to design a data model

Data modeling best practices

Data modeling tips & tricks

Prepare for Your Project

© SAP AG MDM400 3 - 2

© SAP AG 2007

Prepare for Your Project: Unit Objectives

After completing this unit, you will be able to:

Explain the different approaches on how to collect requirements for a Data Model

Review the Tips & Tricks when defining a Data Model

© SAP AG MDM400 3 - 3

© SAP AG 2007

Prepare for Your Project: Course Overview Diagram

General Introduction into Data Modeling

MDM Data Modeling Basics


MDM Project Case Study

© SAP AG MDM400 3 - 4

© SAP AG 2007

Prepare for Your Project: Business Example

Your company plans to implement MDM. To get first experience with the MDM Data Modeling approach, you were tasked to develop a data model for business partners.

© SAP AG MDM400 3 - 5

© SAP AG 2007

Steps to Perform to Develop a Data Model ‒Unit Overview Diagram


Lesson 1: Steps Required to Design a Data Model

Lesson 2: Data Modeling Best practices

Lesson 3: Data Modeling Tips&Tricks

© SAP AG MDM400 3 - 6

© SAP AG 2007

The Process of Creating a Data Model ‒ Lesson Objectives

After completing this lesson you will be able to:

Perform the right steps to define a data model

Tell on how to differentiate a well-defined data model from a data model with limitations

© SAP AG MDM400 3 - 7

© SAP AG 2007

The Process of Creating a Data Model ‒ Business Example

A company would like to consolidate their business partners using a master data management solution. There iss an uncertainty on which kind of data are really master data and what are not. Different people have different opinions on it.

© SAP AG MDM400 3 - 8

© SAP AG 2007

Data modeling can take one of three main forms:

Conceptual data model

Logical data model

Physical data model

What Is Used as a Basis to Start with?

© SAP AG MDM400 3 - 9

© SAP AG 2007

Data Modeling in SAP NetWeaver MDM

Pro: Easy to understand for stakeholdersCon: Conceptual data models typically have the least amount of information.

Customer(name)

Address(street)

John SmithSally SmithSally Smith

-Bob Jones

123 Main St.123 Main St.456 Elm St.789 Oak St.333 Birch St.Copyright 2002 – 2006

Scott W. Ambler

LIves at

Conceptual Data Models:

Explore domain concepts with project stakeholders. Conceptual data models are often created as the precursor to logical data models or as alternatives to logical data models.

Example:

© SAP AG MDM400 3 - 10

© SAP AG 2007


Pro: Provides information about table schemaCon: Can rapidly become very complex

TCUSTOMER_ADDRESSTCUSTOMER TADDRESS

# ADDR_ID: integerADDR_STREET: char(40)ADDR_CITY: char(20)ADDR_ZIP: char(20)ADDR_STATE_CODE: char(2)ADDR_COUNTRY_CODE: char(3)

# CUST_NO: integer# ADDR_ID: integerADDR_USAGE_CODE: char(2)

# CUST_NO: integerCUST_SOCIAL_SECURITY_NO: char(10)CUST_FIRST_NAME: char(20)CUST_SURNAME: char(20)CUST_SALUTATION: char(5)CUST_PHONE_NO: char(20)

Physical Data Models:

Design the internal schema of a database, depicting the data tables, the data columns of those tables, and the relationships between the tables.

Example:

© SAP AG MDM400 3 - 11

© SAP AG 2007


Pro: Provides information about entity relationshipsCon: Still too simple

Customer Address

StreetCityStateCountryZip Code

Customer NumberSocial Security NumberFirst NameSurnameSalutationPhone Number

has

Logical Data Models:

Depict the logical entity types, typically referred to simply as entity types, the data attributes describing those entities, and the relationships between the entities.

Example:

© SAP AG MDM400 3 - 12

© SAP AG 2007

What is the Approach in MDM?

Relational data modeling with the identification of primary/foreign keys.

Data modeling in MDM uses primary keys, display fields, unique constraints

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

© SAP AG MDM400 3 - 13

© SAP AG 2007

Contains a limited number of tables and fields

Is easy to navigate in the MDM Data Manager

Is performant during search & maintenance of records

Is free of workarounds

Shows good performance during import load & syndication

How to Identify an Optimized Data Model

An optimized Data Model

During data modeling the boundaries of the MDM data modeling capabilities need to be considered. Often customers try to bend the functionality to make it work for their requirements. This often causes problems later on, e.g. with either navigation in 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 are looking for in the data manager, the model is well defined. Vice versa you can say, that e.g. using workarounds (such as pointing to other fields in the data manager for building of relationships) sometimes cause problems from a navigational point of 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 then the above checks can give you direction on which one is the best fit.

© SAP AG MDM400 3 - 14

© SAP AG 2007


1. Determine the scenario to be runRationale: Each scenario (e.g. content consolidation, central master data management) has different requirements regarding the data model.

2. Determine the master data objects to be modeledRationale: There are currently 7 supplied data models. Determining the master data objects to be modeled would focus the project scope. What’s your main table object ?

3. Determine the remote systems containing the master data objects to be modeled

Rationale: Determining the total landscape of remote systems provides the raw material for data modeling

Identifying the main table object for your repository is the entry step into defining a data model. Since it is currently possible to have only one main table per repository, it is crucial to select the right object for the main table.

Ways on how to recognize and determine the main table object:

The main table object represents the main object for your business. Similarly, you can ask what result set the system is to deliver when you perform a search for an object.

Example on a discussion about finding the maintable object. A company sells own products and also products it sells as retail items. One and the same product can be ordered from several different suppliers. In this case, the main table object can be either the product itself or the combination of product and supplier. If certain information is maintained supplier-specific, then the main table object should be the product/supplier combination.

© SAP AG MDM400 3 - 15

© SAP AG 2007


4. Determine the data elements from each remote system’s master data object. These might become “fields” in MDM.

Rationale: Not every field needs to go into MDM. Determining synergies between fields.

5. Determine which data objects (“fields”) are:Global--used across all remote systems and which are

Local--used in a subset of remote systems

Master Data

Reference Data

Process Control Attributes

6. Determine the required search strategiesRationale: Required search strategies will require attention to field types

© SAP AG MDM400 3 - 16

© SAP AG 2007


7. Determine if hierarchies are parent of your model.Rationale: If there are Parent/Child/Sibling relationships between records within a table (no search nor syndication possible)

8. Determine if classification is needed. This will determine your “taxonomy.”

Rationale: This will determine the structure and extent of your taxonomy

9. Determine if there are any dependencies between data objects

Rationale: This will help to determine field and table types

10. Arrange the data elements (“fields”) into logical groupingsRationale: This will help to determine the tables to be created

11. Determine the relationship between the tablesRationale: This will help to determine field and table types

E.g. to model 1:n relationships from a main table record to a lookup table record (samples are pricing for materials, e-mail adresses for customers, phone-numbers for customers)

If table records are somehow related together (e.g. storage locations as main table objects –locations belong to states, states can belong to regions, regions belong to coutries), 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 structuring makes it also easier to find later-on records in lookup tables. Going back to the example about different locations if there are several hundred location records stored 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 to find the right location starting e.g. with the country, going down to the region, etc.

Taxonomy tables can be used if you have to classify records according to certain attributes. 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 respective attributes for the record are determined automatically.

Taxonomies can be defined only for the main table.

Even when it is possible to have several taxonomies for a main table, it is recommended to define only one taxonomy.

© SAP AG MDM400 3 - 17

© SAP AG 2007


12. Determine the types of each tableRationale: This will help to choose a table’s function within the repository

13. Determine properties for fields and tables like e.g.Unique FieldKey-mapping Rationale: To improve Data quality

14. Determine whether each data element will relate to the entire record domain or only a subset of the domain:

Entire domain → field

Subset of domain → attribute in combination with Taxonomy

Rationale: This will determine if data elements are placed in tables or in the taxonomy and determine the physical characteristics ofyour main table records

Unique fields: Even when it is not mandatory for a repository, some fields should be defined as unique. Unique fields are useful to avoid redundancy within the repository 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 be performed also based on a unique key. A typical use-case for such a matching would be e.g. the load of records from a legacy system into MDM with following shutdown of the legacy system (in this case storing of key-mapping would not be necessary). To find the right records in the MDM system, you could perfrom the matching based on a unique field.

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

There are two types of 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 data import or manually in the data manager either calling the key-mapping functionality or merging records together.

Remote keys are performance sensitive – so use them wisely and only if needed.

© SAP AG MDM400 3 - 18

© SAP AG 2007


15. Determine if fields in the main table have any dependency on values of another field

Rationale: This will determine if fields are placed in qualified tables

16. Determine if records in tables relate to one another asParent/Child or

Siblings

Rationale: To be able to design relationships for later assignment

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

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

Example 1: Part A replaces Part B starting from April 1.st 2007.

Example 2: Part A can be cross-selled with Part C starting from March 1.st 2007 – March 31.st 2007.

To define models for above examples, it is necessary to use a workaround definition for relationships.

…

© SAP AG MDM400 3 - 19

© SAP AG 2007


17. Determine validations for fieldsRationale: To improve Data quality

18. Normalize tables and fieldsRationale: Reduce data redundancy

19. Denormalize tables and fieldsRationale: To improve performance

20. Create sample records in the new repositoryManually via MDM Data manager

Automatically via MDM Import Manager

Rationale: To test usability of the repository

Validations are useful to improve the Quality of your master data. One business case for validations is e.g. the syndication of master data into remote systems. E.g. when syndicating a material into a SAP ERP Central Component (SAP ECC) Client system it is required that the unit of measure field is populated. Defining a validation – which is called automatically during data maintenance in the MDM Data 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 right values

© SAP AG MDM400 3 - 20

© SAP AG 2007

Steps to perform to develop a Data Model : Lesson Summary

You should now be able to:

Tell how to differentiate a well-defined data model from a data model with limitations


© SAP AG MDM400 3 - 21

© SAP AG 2007

Data Modeling Best practices : Unit Overview Diagram





© SAP AG MDM400 3 - 22

© SAP AG 2007

The process of creating a Data Model : Lesson Objectives

After completing this lesson, you will be able to:

Avoid pitfalls during the definition of a Data Model

© SAP AG MDM400 3 - 23

© SAP AG 2007

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

The process of creating a Data Model : Business Example

© SAP AG MDM400 3 - 24

© SAP AG 2007

Lessons Learned: Repository Design (1)

SAP NetWeaver MDM is not a data modeler tool

Customers with extensive database experience tend to want to use SAP NetWeaver MDM as a data modeler tool.

Although SAP NetWeaver MDM sits in the persistence layer, it is a logically savvy module and performs lots of complex actions behind the scene – isolating the model designers from much of such routine.Example: one should not model a hierarchy structure by using three independent tables in SAP NetWeaver MDM since SAP NetWeaver MDM already provides the necessary structure.

MDMX

© SAP AG MDM400 3 - 25

© SAP AG 2007

Lessons Learned: Repository Design (2)

Do not freeze the model permanently!

Sometimes project managers want to freeze the schema and mark the task off of the project plan as completed.

It is often necessary to model and re-model, and re-model again. Remember that the modeling process is iterative and repetitive. Although the modeling process should appear on the project plan, it is suggested that it assumes 80% of completeness of the repository.

80% Done!

© SAP AG MDM400 3 - 26

© SAP AG 2007

Best Practices ‒ Governance Model

Governance ModelDictates the Data Model•Technical restrictions•Object dependencies•Validation rules

Build a data governance model for all parts of the master data object (even though they will not be maintained or harmonized within MDM) and break it done to each field.

With regards to the needs of the back-end systems, carefully evaluate for which fields it makes sense to keep them in MDM. Exercise: Find the enterprise-wide relevant parts of the data model.

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

Every field that is added to the data model brings complexity in terms of access control, validations, technical design of the field, and distribution. This is especially important for CMDM scenarios.

For a pure consolidation scenario.

Evaluate the data quality in the back-end systems carefully

Pick the data elements providing a good quality to be used for the matching

Map the data models

Keep the data model as slim as possible

© SAP AG MDM400 3 - 27

© SAP AG 2007

Best Practices ‒ Field Conformance

Do not include fields which are not part of the data model• Violate governance model• Degenerate performance

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

Do not include fields to the data model for which the technical restrictions, the governance model, the dependencies to other parts of the object data and the validation 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?

© SAP AG MDM400 3 - 28

© SAP AG 2007

Best Practices ‒ Careful Planning

Careful planning is not limited only to the main table!

If the users need to have additional information to fulfill their tasks, that are not really part of the master data (transactional data). Avoid to load this data into MDM, instead try to use the Portal and/or WebPane in order to expose this information to the user.

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

Data modeling is a complex task, estimate enough time during the project to achieve the necessary quality.

Careful planning is not limited to the main table!

© SAP AG MDM400 3 - 29

© SAP AG 2007

Naming Conventions

Table Names should be plural.

Name of the table should not be replicated to the fields.

Table names should be plural .

Name of the table should not be replicated to the fields.

© SAP AG MDM400 3 - 30

© SAP AG 2007

Best Practices ‒ Keyword Search

Large number of keywordsearches negatively impactsMDM performance.

The usage of the keyword search has a negative impact on performance, especially during the loading and periodic maintenance steps of the repository plus the import of records.

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 the customer requirements.

© SAP AG MDM400 3 - 31

© SAP AG 2007

Best Practices ‒ Sorted Fields

Large number of sorted fieldsnegatively impactsMDM performance.

The usage of the keyword search has a negative impact on performance, especially during the loading and periodic maintenance steps of the repository plus the import of records.

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

© SAP AG MDM400 3 - 32

© SAP AG 2007

Display Fields

Display Fields maydisplay unwantedinformation.

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

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 by the 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. If this concatenated string exceeds the length of the data field, information gets lost!

© SAP AG MDM400 3 - 33

© SAP AG 2007

Qualified Tables (1)

Qualified Tables are used to store relationship dependent information between the main table object and the sub-object. The information lifecycle is bound to the lifecycle of the relationship itself. Hint: Think in an object oriented way.

-VendorID : Text[DF]-Name : Text-Bank Details : Lookup[QualifiedFlat]

«main»Vendor-BANK_ID : Text[DF]-Swift Code : Text-Name : Text-Street : Text-Postal Code : Text-City : Text-Country : Text-Bank Number : Integer-Bank Group : Text-Bank Account Number : Text[qualifier]-Bank Control Key : Text[qualifier]-Account Holder : Text[qualifier]

«qualified flat»Bank

-Addresses

1

-Address Type

n

-VendorID <PK>-Name-Description-Bank <FK>

Vendor-BANK_ID <PK>-Swift Code-Name-Street-Postal Code-City-Country-Bank Number-Bank Group

Bank

-Bank Account Number-Bank Control Key-Account Holder

Bank Details

1

-Addresses

n

-AddressType_ID

OO Model

MDM Model

DB Model

Non Qualifier

Qualifier

© SAP AG MDM400 3 - 34

© SAP AG 2007

Qualified Tables (2)

Is “List Price”dependent on thequalified link?

Order determined automatically

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 are not linked directly to the sub-object and are not dependent on the qualified link between the main object and the sub-object.

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

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

Attention: The qualified links are ordered automatically by the system. Keep this in mind for scenarios, where the order of the qualified links is important! E.g. integration to ERP IS-H: ingredients for medical materials.

Context: If you need to represent a deeply-structured data model on MDM (more than 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 the distribution. The syndicator cannot do this, this needs to be done on XI or in the back-end inbound processing!

© SAP AG MDM400 3 - 35

© SAP AG 2007

Relationships

Syndicationnot possible

Alternatives:Qualified tablesFlat lookup tables

If relationships are used during the data modeling, keep in mind that they cannot be distributed via the MDM syndicator.

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

© SAP AG MDM400 3 - 36

© SAP AG 2007

Key Mapping – Use it Economically

Is Key Mapping needed for Syndication?

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 table as well as all subtables that are relevant for the distribution. (This is a good point in the project to consider and check the possibility for customizing consolidation on back-end systems for the check tables in scope.)

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

© SAP AG MDM400 3 - 37

© SAP AG 2007

Hierarchies

Distribution to a flat structureSyndicator View

Data Manager View

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 exported in the context of another object with a lookup relation to the hierarchy table.

A workaround can be built based on that to distribute hierarchies but this is not automatically controlled by the system and might lead to inconsistencies over time. A control mechanism need to be established!

© SAP AG MDM400 3 - 38

© SAP AG 2007

Look Ups ‒ Check Tables

Check Tables add overhead

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

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

Check tables also need to have governance model and, if relevant for distribution, need to be maintained and synchronized with the back ends.

A foreign key relation to a check table in a back-end system does not always imply the use of a check table on MDM, but gives a good hint to evaluate on it.

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

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

© SAP AG MDM400 3 - 39

© SAP AG 2007

Check Tables

Use Checktables only, when they’re linked to the maintable.

Doing otherwise adds additional overhead to a repository.

If you e.g. want to validate, whether an entered Street/City/ZIP-Code combination is valid, then this is typically done by a third party product, which is called e.g via a webservice.However, if you would like to do this on your own, then you should store this information not in a lookup-table, which is getting called then from your application. MDM repositories are performance optimized for main-table access. Reading large volumes of data from lookup-tables causes performance problems. Lookup tables should always have only a limited number of records.Solution in such a case would be toeither defining a second repository where all these value combinations are stored in the main-table and this repository would be accessed for validation. If a Custom Ui is developed, than this can be considered in the program coding, if Data Maintenance via the Data Manager is planned, then it would be required to have two Data Manager sessions open.store this information in a normal Database table, which is accesed from a program.

© SAP AG MDM400 3 - 40

© SAP AG 2007

Data Consistency

Example: Governance Rule for Taxonomy

enforced by security

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 MDM side cannot cover the full distribution, leverage the functionalities of other NetWeaver components to support the distribution. For instance, representation of deep structures in the MDM data model can be controlled by the users’ knowledge, UIs and validations. The distribution needs to be controlled by XI to ensure the correct context.

Consider the authorization during modeling, to control and support the data governance model on MDM.

Guide users through the maintenance process.

For every field in the solution data model (not only MDM) there should be a single point of access to create and maintain. (Unfortunately this goal is not always possible to achieve.)

© SAP AG MDM400 3 - 41

© SAP AG 2007

Carefully Investigate the Use of Workarounds

Often they work for small amount of record numbers in a repository

E.g. hierarchy table vs. nested lookup tables

In large repositories they could cause performance problems for imports or searches and as well for loading the repository

© SAP AG MDM400 3 - 42

© SAP AG 2007

Addition considerations

Multilingual Repositories Define only these languages, you really need.

SAP predelivered repositories contain numerous languages by default. Eliminate all unneeded languages from the repository, which will result in an increased performance.

Calculated fields Minimize use of Calculated fields

Calculations are performed during each repository load. Depending on complexity of formulas and number of records system performance is impacted heavily

© SAP AG MDM400 3 - 43

© SAP AG 2007

Steps Required to Develop a Data Model ‒ Lesson Summary


Avoid pitfalls during the definition of a data model

© SAP AG MDM400 3 - 45

© SAP AG 2007

Data Modeling Tips & Tricks ‒ Lesson Objectives

After completing this lesson you will be able to:

List the various tips to solve specific problems that usually occur in many projects

Avoid pitfalls that might cause problems at a later point in time

Learn when to use one repository versus several repositories for a business problem

© SAP AG MDM400 3 - 46

© SAP AG 2007

Data Modeling Tips & Tricks: Business Example

Your company is implementing MDM. You plan to implement several object types in parallel. During the design phase, it turns out, that similar problems come up across various different object types, e.g.

When to consider a Data Model final

How to use a common nomenclature for your repositories

How to optimize performance for your repositories

© SAP AG MDM400 3 - 47

© SAP AG 2007

One Repository or Two?

Use case: Material repository should contain also supplier informationCase for one repository

Supplier info is limited (e.g. just name and address) and does not need to be maintained in qualified tables

Case for two separate repositories (one for Material one for Supplier)

Supplier info is more complex, e.g different addresses per supplier and requires data to be maintained in qualified tablesNo out-of-the-box cross-repository communication Customized API program for syndication requiredIntimate coupling of repository structures and business rulesFuture upgrades are getting complex

© SAP AG MDM400 3 - 48

© SAP AG 2007

One Repository = System of Record and Reference?

Use case: A company sells own-developed and manufactured products (ERP product; system of record) and also sells complementary products provided by suppliers (Supplier product; company does not maintain this data; system of reference) [System of record and system of reference in a single repository?

Solution Use a single repository, if

Total Number of records can be handled within one repositoryERP product view and Supplier catalog view are very similar

Prevent changes of Supplier-relevant data via constraints

© SAP AG MDM400 3 - 49

© SAP AG 2007

Relationships with Time Dependency

Use case: MDM relationship table does not allow to store Date/Time Info for a relationshipExample: A specific material is getting replaced by another material on 1/1/2006Workaround solution

Use of a qualified table defining the relationship type and the validity

ConstraintsNavigation in data manager becomes complexRecommendation: Use custom UI to handle maintenance of relationshipsOwn logic required to select the right record at a certain timeNo enforcement of integrity possible

The above business case can be solved by using a qualified lookup table to store the relationship information.

© SAP AG MDM400 3 - 50

© SAP AG 2007

Taxonomy Attributes Reuse (1)

Use case: Different Attribute values depending on Category levelExample: An attribute color should have different values, depending on whether it belongs to a category “Furniture”or to a category “Clothes”Solution 1 (one attribute with a “long” list of values)Constraints

Data entry might be complicated (use of allowed attribute values for furniture); validation formula might helpNo problems in Search (only valid options are shown)No enforcement of business rule

Solution 2 (two “different” attributes with different names) to prevent log value listConstraints

Enforces the business rules

© SAP AG MDM400 3 - 51

© SAP AG 2007

Taxonomy Attributes Reuse(2)

Use case: Different categories in different branches have exactly the same attribute including also the same attribute values

Example: An attribute color should have different values, depending on whether it belongs to a category “Furniture” or to a category “Clothes”

Solution

Attributes, which are shared across, should be promoted to superclass

ConstraintsNo constraints

© SAP AG MDM400 3 - 52

© SAP AG 2007

Data Modeling Tips & Tricks ‒ Lesson Summary


List the various tips to solve specific problems that usually occur in many projects

Avoid pitfalls that might cause problems at a later point in time

Learn when to use one repository versus several repositories for a business problem

© SAP AG MDM400 3 - 53

© SAP AG 2007

Prepare for Your Project ‒ Unit Summary


Tell on how to differentiate a well-defined data model from a data model with limitations


unit_03_ppt_for xml

Documents

data model sap ag mdm400

data tables

kind of data

data columns

welldefined data model

project sap ag mdm400

logical data models

limitations sap ag mdm400