|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|AttributeProperties||An interface defining common attribute properties.|
|DimensionsManager||Interface of dimensions manager giving the set of method for exploring dimensions and units of measure.|
|TableSchema||This interface represents table metadata.|
|AbstractAttributeProperties||An abstract class for common attribute properties.|
|CoupledAttributeProperties||Defines a coupled attribute.|
|DimensionProperties||This class represents a MDM dimension such as length, weight etc.|
|Dimensions||Deprecated. Instead of this class it is recommended to use
|FieldKeywordType||The FieldKeywordType class contains a list of enumerations of supported field keyword type.|
|FieldProperties||This class represents a MDM field.|
|FieldSortType||The FieldSortType class contains a list of enumerations of supported compare type.|
|MeasurementProperties||Defines a measurement.|
|NumericAttributeProperties||Defines a numeric attribute.|
|RelationshipProperties||Defines a relationship.|
|RemoteSystemProperties||Defines a remote system.|
|TableProperties||This class represents a MDM table.|
|TableUniqueConstraint||TableUniqueConstraint specifies the unique constraint set on a table.|
|TextAttributeProperties||Defines a text attribute.|
|TextAttributeValueProperties||Defines a text attribute value.|
|UnitProperties||This class represents a MDM unit, such as an inch, a milligram, etc.|
Provides supporting interfaces and classes for the schema commands.
An MDM repository consists of the following tables:
The main table consists of the primary information about each main table record. For example, an MDM repository of product information would include an individual record for each product and an individual field for each piece of information that applies to all products, such as SKU, product name, product description, manufacturer, and price. Most of the time you will be looking at information in the main table
An MDM repository can have any number of subtables. A subtable is usually used as a lookup table to define the set of legal values to which a corresponding lookup field in the main table can be assigned; these tables hold the lookup information. For example, the main table of an MDM repository of product information may include a field called Manufacturer; the actual list of allowed manufacturer names would be contained in a subtable. Only values that exist in records of the subtable can be assigned to the value of the corresponding lookup field in the main table.
Object tables, including the Images, Sounds, Videos, Binary Objects, Text Blocks, Copy Blocks, Text HTMLs, and PDFs tables, are a special type of lookup subtable, where each object table is used to store a single type of object. You cannot store an object directly in a main or subtable field in an MDM repository. Instead, each object is defined or imported into the repository once and then linked to a main or subtable field as a lookup into the object table of that type.
Fields are contain within a table. They define the data values that makes up a record. There are many field types supported by MDM. For more information, please refer to the MDM Console Reference Guide under the chapter Basic Concepts.
Relationships is a special repository object with a predefined set of fields, and records that that appear in the top-right Relationships pane of the MDM Console. Each record that you add in the MDM Console defines a particular product-level relationship, chosen from among several different basic structural relationship types.
NOTE: A relationship defines the type of relationship but does not specify any of the records that participate in that relationship. For each relationship defined in the MDM Console, you specify the related products and/or non-products for each record in Record mode within the MDM Client.
Any logical system that can supply data to or receive data from MDM is known as a remote system.
MDM can import data from remote systems and create/update master data objects using that data. Master data objects include main table records, subtable records / lookup values, and text attribute text values.
When data is changed in a remote system, the changes can be imported into MDM. Using previously created structural and key mappings, in conjunction with dynamically reconfigurable transformations and mappings, the data is applied to the master data objects. All changes to master data objects are tracked.
At any time, master data objects can then be distributed to all known remote systems through a process known as syndication. This involves determining which master data objects need to be distributed and converting them into a form that the remote system can understand.
NOTE:The remote system concept supports a number of features related to consolidation and distribution by bundling all sorts of useful information related to a particular outside system, including key mapping, import maps, syndication maps, and various timestamps.
With remote systems as a foundation, an MDM port encapsulates all of the configuration and logistical information associated with inbound and outbound processing of data from these remote systems.
In so doing, it simplifies the process of: (1) delivery and consolidation of raw data from remote systems into MDM using the MDM Import Manager; and (2) extraction and distribution of data from MDM to remote systems using the MDM Syndicator.
In each case, the port represents the logical point of contact between MDM and the outside world (e.g. XI or a user of the MDM Import Manager). Within the MDM Import Manager and MDM Syndicator, it represents the physical staging location of data and a logical handle by which to identify all of the encapsulated information.
NOTE: Along with simplifying the user interaction, ports also lay the foundation for future automation of the consolidation and distribution processes within MDM.
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
Copyright 2004-2007 by SAP AG. All Rights Reserved.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (SAP Group) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.