MDM050
Master Data Management
-Overview
SAP NetWeaver Date Training Center Instructors Education WebsiteParticipant Handbook
Course Version: 92 Course Duration: 3 Days Material Number: 50095298No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered 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 trademarks of Citrix Systems, Inc.
• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide 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.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING
WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic conventions are also used.
Type Style Description
Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.
Also used for cross-references to other documentation both internal and external.
Example text Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text Exact user entry. These are words and characters that
you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Pointed brackets indicate that you
replace these words and characters with appropriate entries.
Icons in Body Text
The 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's presentation.
Course Overview ... vii
Course Goals ...vii
Course Objectives ...vii
Unit 1: Master Data Management ... 1
The Problem of Master Data ...2
SAP NetWeaver MDM Architecture ...8
Unit 2: Data Management in SAP NetWeaver MDM ... 31
Finding and Selecting Data ... 33
Basic Data Maintenance in the Data Manager... 69
Taxonomy and Attributes... 119
Matching Mode ...152
Workflow ...179
Unit 3: Other Components of SAP NetWeaver MDM... 221
Console ...222
Import Manager ...253
Syndicator...279
Unit 4: Security and Auditing ... 297
Users, Roles and Change Tracking in MDM ...298
Unit 5: IT Scenarios ... 325
Consolidating Master Data ...326
Harmonising Master Data...332
Central Master Data Management...341
Unit 6: Business Scenarios... 345
Global Data Synchronisation ...346
Customer Data Integration...354
Rich Product Content Management and Print Publishing ...357
Unit 7: SAP NetWeaver Integration ... 371
This course provides an overview of SAP NetWeaver MDM, including the scenarios supported by MDM, use of the main components, and integration of MDM with other key components in SAP NetWeaver
Target Audience
This course is intended for the following audiences:
• IT and project managers responsible for SAP NetWeaver MDM projects • MDM Solution Consultants
• Project team members
Course Prerequisites
Required Knowledge
• SAP01 SAP Overview
Recommended Knowledge
• SAPNW SAP NetWeaver Overview
Course Goals
This course will prepare you to:
• Understand the scenarios of SAP NetWeaver MDM
• Gain an overview of the main components of SAP NetWeaver MDM • Understand how MDM integrates with other elements of SAP NetWeaver
Course Objectives
After completing this course, you will be able to:
• Explain the architecture and components of SAP NetWeaver MDM • Use the Data Manager to maintain master data in MDM, including the use
of Matching and Workflow
• Perform basic functions in other components of SAP NetWeaver MDM, such as the MDM Console, Import Manager and Syndicator
Unit 1
Master Data Management
Unit Overview
Master data is very important to an organisation, but can also cause many headaches. This unit explores the importance of effectively managing master data, and highlights the advantages of implementing a centralised master data management tools such as MDM.
Unit Objectives
After completing this unit, you will be able to:
• Understand the problems caused by poor master data management, and the advantages of being able to control processes around master data management more effectively.
• Explain the main components that make up SAP NetWeaver MDM, and their purpose.
• Understand key terminology in reference to this architecture, including a basic understanding of table and field types.
Unit Contents
Lesson: The Problem of Master Data ...2 Lesson: SAP NetWeaver MDM Architecture ...8 Exercise 1: MDM Terminology ... 25
Lesson: The Problem of Master Data
Lesson Overview
In this lesson the problems associated with storage of master data in traditional organisational systems are highlighted, and the benefits of implementing a dedicated tool for the management of this master data are introduced.
Lesson Objectives
After completing this lesson, you will be able to:
• Understand the problems caused by poor master data management, and the advantages of being able to control processes around master data management more effectively.
Business Example
Your company is planning to implement SAP NetWeaver MDM, and before learning about this tool, you want to understand why exactly the master data in your organisation needs to be managed more carefully.
What is Master Data?
Master data is the consistent and uniform set of identifiers and extended attributes that describe the core entities of the enterprise and are used across multiple business processes. Some examples of core entities are parties (customers, prospects, people, citizens, employees, vendors, suppliers or trading partners), places (locations, offices, regional alignments or geographies) and things (accounts, assets, policies, products or services). Groupings of master data include organizational hierarchies, sales territories, product roll-ups, pricing lists, customer segmentations and preferred suppliers.
The Master Data Problem
Problems related to the enterprise management of "master" data are more acute than ever. Master data continues to grow and includes both traditional structured information and unstructured content such as documents and images. At the same time, data quality is becoming ever more important as interoperability, supply chain, and regulatory/compliance requirements increase. Enter a title and the conceptual information about this lesson in this section. You can also include additional sections, graphics, demonstrations, procedures, and/or simulations.
Figure 1: Typical Siloed Approach to Master Data
Yet no single enterprise business application has become a true system of record for the enterprise. That's because each application cares only about the portion of master data it needs to process its own transactions. No existing systems look at master data holistically. So, at the very moment when businesses require instant access to high-quality information about core business entities, the facts that describe them are inconsistent, inaccurate, and buried in data transaction structures, databases, content management systems, data marts, spreadsheets, email, or on paper.
The lack of a single consistent enterprise system to manage comprehensive master information results in incorrect answers in business intelligence, undermines customer relationship management efforts, and makes it impossible to consolidate spending across suppliers. These complications slow the launch of new products and expose the company to significant regulatory and government compliance risk.
vendor could be represented in multiple ways within a single system, resulting in suboptimal pricing terms, processing errors, costly delays, lost revenue opportunities, and unnecessary expenditures. If we consider that this can cause problems within a single system, consider the impact on master data that is shared along the supply chain. Incorrectly ordered items due to differences in material descriptions, wastage, and excessive freight charges are just some of the many excess costs that could escalate.
Figure 3: Inconsistent Views of Partner Data
How can you avoid these costly complications? By consolidating your master data and managing it consistently across your enterprise with the SAP NetWeaver Master Data Management (SAP NetWeaver MDM) component. Because SAP NetWeaver MDM supports most data sources, it enables you to leverage your legacy systems and applications. Whatever your industry, you can improve business process efficiency, become more responsive to change, and strengthen your decision making capabilities.
With SAP NetWeaver MDM, you can identify and match suppliers, removing duplicate suppliers in the same system and finding equivalent suppliers in acquired or merged companies. You can then extract, transform, and load data from any number of heterogeneous procurement systems. In addition, you can use external validation services such as a Dun & Bradstreet DUNS number. You can take advantage of the integration of SAP NetWeaver MDM with SAP NetWeaver BW or SAP BusinessObjects BI solutions, which enables you to analyze your spend across heterogeneous systems and organizational boundaries.
Benefits of SAP NetWeaver Master Data Management
SAP NetWeaver MDM helps you accomplish the following.Improve business process efficiency – As a result of delivering consolidated and
reliable master data to your operational systems, you can streamline business processes by eliminating the need for time-consuming manual checks and look-ups. In addition, you can:
• Compose new, innovative processes and access data through Web service • Simplify print-catalog production by disseminating information directly to
Adobe InDesign
• Reduce IT maintenance and operations costs and generate quantifiable ROI
Support decision making – With a single version of the truth, you can drive
better-informed business decisions and improve the reliability of your analyses and reports through data harmonization and integration with SAP NetWeaver BW and SAP BusinessObjects Data Services.
By consolidating, cleansing, and standardizing master data into a centralized repository, you can provide downstream applications with a reliable and accurate master-data source. In addition, you can boost cross-selling and up-selling to improve top-line results.
By identifying relationships between and among entities such as related products, you can expose these relationships in your Web or print catalog, thus increasing each average purchase and improving your internal support processes.
Respond with flexibility to changing business climates – When the business
climate changes, you are better prepared to respond if your master data is well-managed. You are able to meet changing compliance standards for government and industry regulations by eliminating duplicate, incomplete, or outdated information on customers, products, suppliers, and materials. You can better support data governance initiatives with unified data to help ensure maximum returns on BI and enterprise application initiatives.
Features of SAP NetWeaver Master Data Management
• End-to-end solution. The MDM system provides an end-to-end solutionthat automates the entire process of managing master data from start to finish, including bulk data import, centralized master data management, and published output to a variety of media.
• Database-driven system. MDM layers a thick shell of functionality on top
of a powerful SQL-based DBMS so that the MDM system is fully scalable and the master data is fully accessible to other SQL-based applications and tools.
• Large capacity. The MDM system efficiently manages master data
repositories containing up to millions of records.
• Superior performance. MDM breaks through SQL performance bottlenecks
to deliver blazingly fast performance that is measured in milliseconds rather than seconds and is literally 100–1000 times that of a SQL DBMS alone. No other system on the market today delivers comparable performance.
• Powerful search and retrieval. All of the MDM modules include powerful
search and retrieval capabilities, so that an entire repository of thousands or millions of items can be easily searched and any item or group of items located in a matter of seconds.
• Cross-media publishing. The MDM system is the only one on the market
today that includes tightly integrated functionality for both electronic and printed output, for Web, CD-ROM, and paper output from a single MDM repository.
Lesson Summary
You should now be able to:• Understand the problems caused by poor master data management, and the advantages of being able to control processes around master data management more effectively.
Lesson: SAP NetWeaver MDM Architecture
Lesson Overview
This lesson will describe the main components that make up SAP NetWeaver MDM, and cover key terminology in terms of table and field types.
Lesson Objectives
After completing this lesson, you will be able to:
• Explain the main components that make up SAP NetWeaver MDM, and their purpose.
• Understand key terminology in reference to this architecture, including a basic understanding of table and field types.
Business Example
As your organisation is looking to implement SAP NetWeaver MDM, you need to understand what elements make up MDM, and understand key terminology used when using MDM.
What is SAP NetWeaver MDM?
The MDM system is much more than a simple database application. Rather, it is an integrated system for master data management that uses a SQL DBMS but then completely bypasses SQL for almost all searching, sorting, and retrieving of information. Standard SQL does not support the kinds of advanced structures necessary for master data management, so MDM features a database schema structure that is extended and optimized for master data, and powerful tools both for managing information and for classifying it into a hierarchy of categories and subcategories.
The repository structure itself is completely flexible, but whether you have a thousand products in ten categories, or a million products in ten thousand categories, the underlying SQL schema consists of the same standard set of MDM tables, making the system extremely scalable, compact, and fast for large repositories and high-end applications.
What is an MDM Server?
An MDM Server is the central hub of an MDM system. It manages access to master data in one or more MDM repositories, which it serves up to various client applications across a network.
The various components of an MDM software environment, and how they interact with the MDM Server; are described below.
• MDM Console. MDM Console allows system managers to administer and
monitor MDM Servers, and to create, maintain the structure of, and control access to the MDM repositories.
• MDM Clients. MDM clients interact with an MDM Server to import, access,
manage, syndicate, and publish master data. Clients include MDM rich user interfaces such as MDM Data Manager, MDM Import Manager, and MDM Syndicator, as well as customizable interfaces such as iViews and APIs. • DBMS engine. Master data is stored in a commercial SQL DBMS, access
to which is controlled by the MDM Server. MDM supports Microsoft SQL Server, Oracle, IBM DB2, and SAP MaxDB.
Figure 4: SAP NetWeaver Architecture
MDM Auxiliary Servers
In addition to the Master Data Server, an MDM system can include the following auxiliary servers:
• Master Data Import Server (MDIS). Automates import of data into an
MDM repository.
• Master Data Syndication Server (MDSS). Automates syndication of data
from an MDM repository.
• Master Data Layout Server (MDLS). Processes publication of master data
from an MDM repository.
Each of these auxiliary servers interact independently with an MDM Server and, like the MDM Server, can be administered from within MDM Console.
What is an MDM Repository?
The incorrect or at best incomplete answer is often that a master data repository is simply a database. An MDM repository certainly includes a database of information consisting of text, images, PDFs, and other data about each record, up to millions of records for some repositories. But a master data repository is much more than just a large database, and size by itself does not make a database a master data repository. Rather, it is the richness and complexity of the underlying information itself and the ways it can be searched and published that uniquely characterize an MDM repository.
Moreover, when an MDM repository of product information is published as a catalog, the repository of master data becomes a sales tool, listing the products offered for sale by a vendor and allowing potential customers to browse those products in a convenient way. Often, the published catalog is the only point of contact a customer will have with a vendor, which makes the presentation of the product information – the organization and the design of the published catalog – critically important to creating brand recognition and a distinct vendor identity.
Hundreds of details, large and small, must be addressed to turn a database into a meaningful master data repository, including:
• Rich master data. Rich structured, master data is the essential lifeblood of
a usable MDM repository. For example, an MDM repository of product information must contain much more than basic transactional data consisting of just a part number, a price, and a forty-character description for each product. Master data must include not only fields of information common to all the products in the repository, such as part number and price, but also detailed product specifications (attributes) that may apply to only a subset of the products. Master data could also include rich content such as images, text blocks, and PDFs (for MSDS and other data sheets).
• Classification. Rich master data is not enough. The records need to be
organized and classified into a taxonomy consisting of an arbitrary hierarchy of categories and subcategories, the hierarchy may contain any number of levels, and multiple simultaneous taxonomies may coexist in the same MDM repository. And a single category must be able to appear in multiple places within the hierarchy. For example, in an MDM repository of product information, a printer accessories category might be placed under both a printers category and an accessories category.
• Product families. Nodes from the classification hierarchy can be further
partitioned into product families (also called units, presentations, or modules).. A print based product catalog provides an excellent model for how information on groups of records within an MDM repository of product data can be organized in this way. The families further partition the products in each category into smaller groups based upon the values of other fields and/or attributes. In addition to the individual products, a product family includes family data (such as an image, a descriptive paragraph, and feature bullets) as well as detailed specifications on each of the products, arranged into a well-structured tabular layout.
• Product relationships. Relationships can be defined between individual
products, or between categories within the classification schema, based on some common attribute. Relationships include structural relationships, such as assemblies (a “SKU of SKUs”), kits (a “SKU of non-SKUs”), bundles (a “non-SKU of SKUs”), and matching sets (e.g. nuts and screws), as well as merchandising relationships, such as cross-sells, up-sells, accessories, and consumables. An MDM repository of product information must be able to capture and represent all of these product relationships.
MDM Repository Structure
A thorough understanding of the table and data types available for use is essential for properly creating and maintaining MDM repositories. This section provides an
Figure 5: MDM Table Types
• Main tables. Every MDM repository has one or more main tables. A main
table contains primary information about a business object, such as a product or supplier. For example, a repository might contain separate main tables for products and business partners. The products main table would include an individual record for each product and individual fields that apply to all products, such as SKU, product name, product description, manufacturer, price, and business partner. The business partner main table would include an individual record for each partner and individual fields for each piece of information that describes the partner. Most of the time you will be looking at information in a main table.
Note: When you first create a new MDM repository, MDM
automatically creates a main table named Products.
• Subtables. An MDM repository can have any number of subtables. A
subtable is usually used as a lookup table to define the set of allowed values to which a corresponding lookup field in the main table can be assigned; these tables hold the lookup information. For example, a 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 selected in the corresponding field of the main table.
Note: Lookup subtables are just one of the powerful ways that
MDM enforces data integrity in an MDM repository. The set of allowed values associated with lookup fields also makes the MDM repository much more searchable, since a consistent set of values is used across the entire repository.
• Object tables. 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.
Note: Object tables eliminate redundant information, since each
object appears only once in the MDM repository even if it is linked to multiple records.
When you first create a new MDM repository, MDM automatically creates the single instance of each object table.
You can also store text blocks directly in a large text field in main and subtable records rather than as a lookup into a text block subtable if you do not intend to reuse the blocks of text.
• Special tables. Special tables include the Image Variants, Masks, Families,
Relationships, Workflows, Named Searches, Tuples, Data Groups, and Validation Groups tables.
Note: When you first create a new MDM repository, MDM
automatically creates the single instance of each special table. The Data Groups and Validation Groups tables do not appear anywhere in MDM Console.
• System tables. System tables appear under the Admin node in the Console
Hierarchy and include Roles, Users, Connections, Change Tracking, Remote Systems, Ports, Links, XML Schemas, and Reports, and Logs.
Note: When you first create a new MDM repository, MDM
automatically creates the single instance of each system table. The Logs table is MDM Server-specific rather than MDM
repository-specific, and appears in the Console Hierarchy under an MDM Server node after all of the MDM repository nodes.
Table Types
A traditional SQL DBMS stores data in the records and fields (rows and columns) of a collection of flat database tables. All tables have the same rectangular structure in SQL. A SQL database is relational because of the relationships set up between the different tables.
In a relational DBMS (RDBMS), information about a single record can be combined from multiple tables by relating values in matching columns. This helps to eliminate redundant data; beyond that, however, an RDBMS does not support any additional structuring of the data itself.
By contrast, the MDM system supports a variety of different table types that are specifically suited for the particular requirements of storing, organizing, structuring, classifying, managing, and publishing information in an MDM repository (including efficient support for category-specific attributes, which are inherently non-relational), as shown in the following tables.
Main Table and Subtables Table Type Description
Flat Main table or subtable. A flat table has the standard, rectangular SQL structure consisting of records and fields (rows and columns). The main table of an MDM repository is always a flat table.
Hierarchy Subtable. A hierarchy table organizes information in a hierarchy, where each record is related to a parent record (even if the only parent is the root) and may also be related to sibling records and/or child records. The main table in an MDM repository typically contains some fields whose data may be hierarchical in nature. For example, a Manufacturer field may need to accommodate division and subdivision information for manufacturers. This hierarchical information is stored in a separate, hierarchy subtable associated with the Manufacturer lookup field in the main table. Note that a hierarchy table is useful even when it is flat (i.e. only leaf nodes below the root), because it stores the ordered sequence of sibling records, allowing you to override the unordered sequence of values in a flat table.
Taxonomy Subtable. A taxonomy is the classification scheme that defines the categories and subcategories that apply to a collection of records. Categorizing records enables you to isolate subsets of records for various organizing, searching, editing and publishing purposes. A taxonomy table in MDM stores a hierarchy of categories and subcategories and also supports attributes, “subfields” that apply to particular categories rather than to the entire collection of records. MDM supports multiple simultaneous taxonomies.
Qualified Subtable. A qualified table in MDM stores a set of lookup records, and also supports qualifiers, “subfields” that apply not to the qualified table record by itself, but also 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-based search, and also to store any large set of subtable records that contain fields whose values are different for each main table record, such as multiple prices for different quantities, divisions, regions, or trading partners, cross-reference part numbers, and additional distributor/supplier/customer-specific information for different distributors, suppliers, or customers.
Object Tables
Table Type Description
Images A single table named Images. Stores image files, where each image is stored as a record in the table.
Text Blocks A single table named Text Blocks. Stores blocks of text, where each text block is stored as a record in the table.
Copy Blocks
A single table named Copy Blocks. Stores blocks of text interpreted as copy, where each text block is stored as a record in the table.
Text HTMLs
A single table named Text HTMLs. Stores blocks of text interpreted as HTML, where each text block is stored as a record in the table.
PDFs A single table named PDFs. Stores PDF files, where each PDF is stored as a record in the table.
Sounds A single table named Sounds. Stores sound files, where each sound file is stored as a record in the table.
Videos A single table named Videos. Stores video files, where each video file is stored as a record in the table.
Binary Objects
A single table named Binary Objects. Stores other binary object files, where each binary object file is stored as a record in the table.
Special Tables
Table Type Description
Masks A single hierarchy table named Masks. In concept, a mask acts like a stencil, in that it blocks (“masks”) all main table records from view except the defined subset of records that are included in the mask, to allow the subset to be viewed and manipulated as a whole. A mask is a static snapshot of the set of records that are included in the mask (as opposed to a view or a named search, where the results set is determined dynamically every time the search is run). Each record in the Masks table is the name of a subset of main table records. MDM supports an unlimited hierarchy of masks.
Named Searches
A single flat table named Named Searches. A named search is a static snapshot of the search selections that were in effect when the named search was saved (as opposed to a mask, which is a snapshot of the subset of records), where the results set itself is determined dynamically when it is selected. Each record in the Named Searches table returns a subset of a main table’s records. MDM supports 400 named searches per repository.
Families A single hierarchy table named Families. Used to further partition main table records in each category into smaller groups based upon the values of other fields and/or attributes. You can associate family data (a paragraph, an image, bullets) once with a family of products rather than with each individual product, and also define the table layout of the field and/or attribute data (field order; stack, vertical, and horizontal pivots; and other display options).
Image Variants*
A single table named Image Variants. Used to define the structure and format of each of the variants for each image. Each variant is a modified version derived from an original image; the original image is never modified. This table is managed in the MDM Console and is not visible in the MDM Data Manager.
Relation-ships*
A single table named Relationships. Used to define each of the different record-level relationships. Each relationship can be either bidirectional (sibling) or unidirectional (parent-child). This table is managed in the MDM Console and is not visible in the MDM Data Manager.
Workflows A single table named Workflows. Stores the workflows of an MDM repository, where each workflow is stored as a record in the table. Workflows are created and edited in the MDM Data Manager.
Data Groups A single hierarchy table named Data Groups. Stores the hierarchy of data groups used to break the entire set of objects in the MDM repository into manageable subgroups.
Validation Groups
A single hierarchy table named Validation Groups. Stores the hierarchy of validation groups used to organize multiple validations for subsequent execution as a group.
* These tables do not appear in the MDM Data Manager
System Tables
Table Type Description
Roles* A single table named Roles. One of three tables used to implement MDM repository security and access control. Each role can selectively grant or deny access to any MDM function and to any table or field. This table is managed in the MDM Console.
Users* A single table named Users. One of three tables used to implement MDM repository security and access control. Each user can have one or more roles. This table is managed in the MDM Console.
Logins* A single table named Logins. One of three tables used to implement MDM repository security and access control. Contains an entry for each currently connected MDM client application, which can be terminated by the MDM Console user. Change
Tracking*
A single table named Change Tracking. Allows you to specify the fields for which adds, modifies, and deletes should be tracked and stored in the Change Tracking table.
Remote Systems*
A single table named Remote Systems. Used to define the different remote systems for import and export. Each remote system specifies whether it supports import only, export only, or both.
Ports* A single table named Ports. Used to encapsulate the logistical and configuration info for inbound and outbound processing of MDM data, for consolidation and distribution respectively. URLs* A single table named URLs. Used to specify the URLs that can
be used as the target of an embedded browser in the Web tab in the MDM Data Manager.
XML Schemas*
A single table named XML Schemas. Used to identify the XML schemas for import and syndication. Each XML schema is the name of an .xsd file.
Reports* A single table named Reports. Contains an entry for each report file generated by the various MDM repository operations, which can be accessed and viewed by the MDM Console user.
Logs* A single table named Logs. Contains an entry for the log files generated by the MDM Server, which can be accessed and viewed by the MDM Console user.
* Does not appear in the MDM Data Manager
Data Types
A traditional SQL DBMS has a standard set of relatively simple data types (such as text, integer, and real) that allow you store a single element of unstructured data in each field. Beyond knowing how to accept input of and properly store each type of data, SQL has no real understanding of the internal structure of each data element. By contrast, an MDM repository supports a variety of compound and structured data types that, like the set of MDM table types, are specifically suited for managing information in a master data repository.
Note: In the tables below, a bullet (•) in the column labelled “MV” means
that the data type can be defined as multi-valued, so that a single field or attribute can be used to store multiple values. Multi-valued fields and attributes make the structure of an MDM repository dramatically simpler, more compact, and more searchable, by allowing you to store 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 a maximum of one field or attribute for each possible value.
Data Type MV Description
Text Normalised
Text field with “special” (non-alphanumeric) characters removed, for searching/sorting (always displays original). Name Text field with internal structure for storing parts of a name
(e.g. prefix, first, middle, last, suffix)
Log Text large field with internal structure for managing multiple time stamped blocks of text within a single field.
GM Time Time stamp field that has been adjusted to a particular time zone.
Measure-ment
• Real field with associated unit of measure. Literal Date Time stamp that ignores the time part. Literal Time Time stamp that ignores the date part. Create
Stamp
Time stamp that MDM automatically sets with the date and time of the record creation.
Time Stamp Time stamp that MDM automatically sets with the date and time of modification when any of the fields being tracked are updated.
User Stamp Text field that MDM automatically sets with the name of the user who makes the change when any of the fields being tracked are updated.
Mask • Virtual field that stores an enumeration of main table records. It is never displayed, but is used for searching. Lookup
[Flat]
• Field whose value(s) are a lookup into a flat table. Lookup
[Hierarchy]
• Field whose value(s) are a lookup into a hierarchy table. Lookup
[Taxonomy]
Field whose single value is a lookup into a taxonomy table. Lookup
[Qualified]
• Field whose value(s) are a lookup into a qualified table. Lookup
[Image]
• Field whose value(s) are a lookup into the Images table. Lookup
[Text Block]
• Field whose value(s) are a lookup into the Text Blocks table. Lookup
[Copy Block]
• Field whose value(s) are a lookup into the Copy Blocks table.
Lookup [Text HTML]
• Field whose value(s) are a lookup into the Text HTML table.
Lookup [PDF]
Lookup [Sound]
• Field whose value(s) are a lookup into the Sounds table. Lookup
[Video]
• Field whose value(s) are a lookup into the Videos table. Lookup
[Binary Object]
• Field whose value(s) are a lookup into the Binary Objects table.
Note: A Text Normalized field stores the actual text value, but uses the
normalized value for sorting and searching. The normalized value is an upper-case version of the original with non-alphanumeric characters removed (includes a-z, A-Z, and 0-9 from original value).
Attribute Data Type
MV Corresponding MDM Field Type
Text • Lookup [Flat] Numeric • Measurement Coupled
Numeric
• n/a
Dimensions and Units
As noted in the tables above, MDM has a compound data type for storing physical measurements that combines a numeric value with a unit of measure. It allows you to associate a physical dimension with a measurement field or numeric attribute, and then to assign to every numeric value a unit of measure chosen from the list of units applicable to that dimension.
MDM currently has built-in support for over 70 different physical dimensions and over 750 different units of measure. In addition, MDM is able to convert between different units, for proper comparison and sorting of numeric values with different units within a list, impossible with most other systems that often store numeric values and units of measure as a single text string or in two distinct fields.
Note: Physical dimensions make it easy to enforce data integrity, since
units of measure must be selected from a predefined list of units rather than typed in by the user as a text string. Measurement fields and numeric attributes are 4-byte real fields with the exception of the dimensions Time and Frequency, which require the additional precision of 8-byte real fields.
In the context of master data management, a taxonomy is what makes it possible to quickly locate a few specific records – or categories – in a database of thousands, tens of thousands, or even millions of records.
A taxonomy is usually hierarchical, meaning that some categories are subcategories of other categories. (In the MDM system, taxonomy tables are always hierarchical.) Most people are familiar, for example, with at least part of the hierarchical taxonomy used to classify animals, such as vertebrates –>
mammals –> primates –> chimpanzees, and so on. Another example that you
might experience in your daily life is groceries –> beverages –> carbonated
–> decaffeinated. Each level of the hierarchy gets narrower in terms of what it
includes. MDM uses a hierarchical taxonomy of categories to structure master data in an MDM repository. A hierarchical taxonomy is typically represented as a “tree”.
Tree Terminology
Terms like node, branch, sibling and child are used in tree commands. You will also find mention of ancestors and descendants in reference to trees.
MDM Tree Terminology Term Definition
Node Any item in the tree. Root node The top node of the tree.
Branch Any node of the tree below the root node.
Parent node The node that is one level above the referenced node. Sibling node Any node that is at the same level as the referenced node. Child node Any node that is one level below the referenced node. Internal
node
Any node that has child nodes. Leaf node Any node that has no child nodes.
Ancestors All nodes at higher levels than the referenced node, including not only parent nodes, but also parents of parents, and so on.
Descen-dants
All nodes at lower levels than the referenced node, including not only child nodes, but also children of children, and so on.
Attributes
In a taxonomy, every category has its own defining characteristics (in addition to those of every category above it in the hierarchy). For example, in the taxonomy of animals, primates have specific characteristics as well as those of mammals and vertebrates.
In an MDM repository, these characteristics are called attributes, and correspond to fields of information that apply only to some, rather than all, of the main table records in the MDM repository. For example, voltage might be an attribute that applies to motors but not to gears.
Every taxonomy table has a pool of attributes associated with it. From this pool you can link attributes to one or more individual categories on a category-by-category basis.
In MDM, attributes are associated with – linked to – categories. When you assign a record to a category, the record acquires the attributes linked to that category and all the attributes linked to its parent category, and all others up the hierarchy, through inheritance. So, a record in the main table consists of common fields, inherited attributes, and category-specific attributes.
Note: In MDM, an attribute is like a field, but one that applies only to a
subset of the records in the main table. By contrast, a field is part of every record in the main table. If a particular attribute can be applied to every main table record, then it should be set up as a field in the main table. For example, every record in an MDM repository of products probably has an item number; therefore “Item Number” should be defined in the database as a field, and not as an attribute.
Product Applications and Application-Based Search
A product application is a particular use of a product. Applications are especially important in certain industries where application-driven product selection is the traditional way to locate products. For example, in the automotive parts business, customers typically select parts based not on the category or manufacturer but rather on the particular year, make, model and engine type of the vehicle. There are millions of parts, tens of thousands of different vehicles, and since each part can be used in more than one vehicle, tens of millions of applications. Finally, the use of the part is often further qualified by specific characteristics of the vehicle, such as whether or not it has air conditioning.
In an MDM repository, product applications stored in qualified tables can dramatically reduce duplication of data. In the automotive example, parts are stored in the main table, the “valid table” of vehicle specifications are stored in a qualified table, and each application of a part to a vehicle is represented by assigning the vehicle specification to the part.
Note that each lookup record in a qualified table is generic, in that it does not include the various conditions that might further qualify the use of the product in that application, even though the particular application may require additional conditions to properly define it. In MDM, these additional conditions are called
In the automotive example, qualifiers allow a single vehicle specification record to be used for vehicles that are equipped differently. This eliminates the explosion of vehicle specifications that normally occurs when the additional conditions for each application result in additional – but almost identical – vehicle specification records, as in most existing application-based systems.
Hint: With or without product applications per se (or the need for
application-based search), a qualified table can also be used to store any large set of subtable records that contain fields whose values are different for each main table record, such as multiple prices for different quantities, divisions, regions, or trading partners, cross-reference part numbers, and additional distributor/supplier/customer-specific information for different distributors, suppliers, or customers.
Exercise 1: MDM Terminology
Exercise Objectives
After completing this exercise, you will be able to: • To assess basic understanding of MDM terminology
Business Example
As your company is implementing SAP NetWeaver MDM you need to be familiar with the basics of the architecture and the terminology used.
Task:
Please answer the following questions.
1. Which of the following are components make up an MDM environment? Choose the correct answer(s).
□ A Server □ B Console □ C Administrator □ D Java Server □ E Printer 2. A repository in MDM contains: Choose the correct answer(s). □ A Only one Main table □ B Always one Customer table □ C One or more Taxonomy tables □ D One Workflows table
3. The Logins table allows you to create users for the repository. Determine whether this statement is true or false.
□ True □ False
4. Fields are available in three types only; text, numeric and coupled numeric. Determine whether this statement is true or false.
5. Fields are applied to all records in the repository, whereas attributes apply only to a subset of records, based on the taxonomy.
Determine whether this statement is true or false. □ True
Solution 1: MDM Terminology
Task:
Please answer the following questions.
1. Which of the following are components make up an MDM environment?
Answer: A, B
From this list only the MDM Server and MDM Console are valid components of SAP NetWeaver MDM.
2. A repository in MDM contains:
Answer: C, D
SAP NetWeaver MDM can contain more than one Main table, and of course, as MDM can support any master data object, there may or may not be a table called Customer.
3. The Logins table allows you to create users for the repository.
Answer: False
The Logins table allows you to track connections to your repository from the MDM Clients and the Auxilliary servers. Users are created in the Users table. 4. Fields are available in three types only; text, numeric and coupled numeric.
Answer: False
These three types listed are the attribute types. There are many more than three field types supported in MDM.
5. Fields are applied to all records in the repository, whereas attributes apply only to a subset of records, based on the taxonomy.
Answer: True
Fields are maintained as part of the table definition, and so apply to all records in the table. Attributes are maintained in Taxonomy mode, and linked to the Taxonomy, and therefore only apply to the specific categories they are linked to.
Lesson Summary
You should now be able to:• Explain the main components that make up SAP NetWeaver MDM, and their purpose.
• Understand key terminology in reference to this architecture, including a basic understanding of table and field types.
Unit Summary
You should now be able to:• Understand the problems caused by poor master data management, and the advantages of being able to control processes around master data management more effectively.
• Explain the main components that make up SAP NetWeaver MDM, and their purpose.
• Understand key terminology in reference to this architecture, including a basic understanding of table and field types.
Unit 2
Data Management in SAP NetWeaver
MDM
Unit Overview
The MDM Data Manager provides a rich interface for managing master data within MDM. In this unit, the use of the Data Manager to search for and maintain master data is explored.
Unit Objectives
After completing this unit, you will be able to:
• Identify the different modes of the MDM Data Manager
• Use the various search features available in the MDM Data Manager • Add, delete, duplicate, check in/out and compare records in record mode. • Use the various techniques for maintaining the record details.
• Understand the concept and maintenance of tuples. • Work with Masks.
• Use Taxonomy mode in the Data Manager to classify master data, and to perform basic Attribute maintenance
• Use Matching Mode to create new rules etc., and execute a matching strategy to merge duplicate data in the repository
• Use workflow to control master data maintenance processes, including the basics of validations
Unit Contents
Lesson: Finding and Selecting Data ... 33 Exercise 2: Data Manager - Finding and Selecting Data... 65 Lesson: Basic Data Maintenance in the Data Manager ... 69 Exercise 3: Basic Data Maintenance in the Data Manager ... 113 Lesson: Taxonomy and Attributes ... 119
Lesson: Finding and Selecting Data
Lesson Overview
This lesson covers the modes of the SAP NetWeaver MDM Data Manager, as well as the various options available for finding and selecting data in the Data Manager.
Lesson Objectives
After completing this lesson, you will be able to:
• Identify the different modes of the MDM Data Manager
• Use the various search features available in the MDM Data Manager
Business Example
When working with master data in MDM, the main UI used by users is the Data Manager. In order to effectively maintain master data, you must first get familiar with the UI, and the various search and selection methods available to you.
Starting and Exiting the MDM Data Manager
Before you begin, you need to be sure that both the SQL DBMS (SQL Server, Oracle, DB2, or MaxDB) and the MDM Server software are up and running, and that the MDM repository you want to work on has been loaded.
To start the MDM Data Manager from either the Desktop or the Start menu: 1. From the Desktop, double-click the MDM Data Manager icon or from the
Start menu, choose Programs > SAP MDM > MDM Data Manager. 2. When the Connect to MDM Repository dialog appears, choose the desired
MDM repository from the drop-down list, choose a language, and enter your user name and password.
Note: If the desired MDM repository does not appear in the
dropdown list, you must first add it to the list by clicking the “…” (browse) button and filling in the required connection information. If a repository’s TCP/IP port number changes, you must re-add the repository to the drop-down list as the old entry will load whatever repository is loaded on the old TCP/IP port.
Figure 6: Data Manager Logon
3. Click OK. After a few seconds, the MDM main window comes up. To exit the MDM Data Manager:
• Click the close button in the upper right corner of the window, or choose File
> Exit from the main menu.
Repository List
You may add entries to the Connect to Repository dialog’s drop-down list of repositories as described below.
To add a new repository entry to the drop-down list of repositories:
1. In the Connect to MDM Repository dialog, click the “…” (browse) button to open the Choose Repository dialog.
2. Type the name of the applicable MDM Server or select one from the drop-down list.
Note: The drop-down list of MDM Servers includes only those
servers that you have previously mounted. If the desired server is not in the list, click the “…” (browse) button to open the Select MDM Server dialog, and select a machine on which MDM Server has been installed from the list of Windows machines visible on the local network. Alternatively (and for all non-Windows installations), type the name or IP address of any remote machine into the edit box in the Choose Repository dialog.
Figure 7: Choose a repository
3. Select an MDM repository from the drop-down list of repositories. 4. Click OK when you are done to close the Choose Repository dialog. 5. MDM adds the repository to the list of repositories in the Connect to MDM
Repository dialog.
MDM Data Manager Modes
The MDM Data Manager operates in five modes. Each mode is designed for manipulating specific types of tables and repository information, as follows: • Record mode. Allows you to search, view and edit the records of any table in
the MDM repository. This is the mode you will use most often, to view and edit records in the main table and any of the subtables.
• Hierarchy mode. Allows you to view and edit the hierarchy tables in the MDM repository, including regular hierarchy tables, taxonomy tables, and the Masks table. Though you can also view and edit the records of a hierarchy table in Record mode, Hierarchy mode specifically allows you to edit the parent/child relationships and the sibling ordering of the hierarchy. • Taxonomy mode. Allows you to view and edit the taxonomy tables in the
MDM repository. You will use this mode to create and maintain the category hierarchy used in the repository, and to manage the attributes pool. Though you can also view and edit taxonomy tables in both Record mode (for searching) and Hierarchy mode (for editing other category fields), Taxonomy mode focusses on management of attributes.
• Matching mode. Allows you to identify and eliminate duplicate records within an MDM repository. When you view the main table in Matching mode, MDM allows you to perform “matching-and-merging” on any records, using various user-defined criteria to decide whether or not records are potential duplicates.
• Family mode. Allows you to view and edit the Families table.
Working with Record Mode
Record mode is used to manage the records of any table in the MDM repository, including the main table, regular subtables, and object subtables.
When you first start the MDM Data Manager, it places you in Record Mode with the connected repository’s main table selected as the current table. You can change tables at any time by selecting a different table from the current table drop-down list.
To switch to Record mode:
• Click the Record Mode toolbar button, or press Ctrl+1, or choose View –>
Record Mode from the main menu.
To specify the current table:
• Click on the drop-down table list or press F4, and select the table whose records you want to search, view, or edit. Alternatively, choose View –>
Figure 9: Drop-down Table List in Record Mode
Hint: If you want to simply review the records in a table and wish to
avoid any accidental changes, you can put the MDM Data Manager into read-only mode by clicking on the Read-Only toolbar button (shown at left), or by choosing View –> Read-Only from the main menu
Search Parameters Pane
The Search Parameters pane (left pane) contains the search tabs for drilldown search, each corresponding to a lookup field in the current table, and one additional tab for free-form search. Use the tabs in the Search Parameters pane to add search selections and narrow down the set of records displayed in the Records pane.
Records Pane
The Records pane (top-right pane) lists the current table’s records in a grid. If there are no search selections, all of the records in the current table are displayed; otherwise, only the records matching the current search selections are displayed. Use the Records pane to browse the records of the current table, sort by any of the sortable columns in ascending or descending order, and to select one or more records for editing, deletion, or other operations.
Note: Attributes do not show up in the Records pane, which displays a
column for each field in a record but none for the attributes. To view the attributes for the records, you must view the record in the Record Detail tab.
Record Detail Tab
The Record Detail tab (tabs pane) displays the field and attribute values of records selected in the Records pane. Inside the tab, each field and attribute name is displayed as a row header with the corresponding value for the selected record(s) appearing next to it. You can edit field and attribute values directly from this tab. If the current table contains lookup fields into object tables, the Record Detail tab is split vertically into two subpanes: the left subpane contains a vertical list of the record’s field and attribute values; the right subpane contains the record’s object lookup field values.
Figure 10: Record Detail Tab
Language Detail Tab
Use the Language Detail tab (tabs pane; multilingual repositories only) to view and edit multilingual data for records selected in the Records pane. The tab contains a multi-column grid with each multilingual field, attribute, and object of the current table displayed as a row and a separate column of data for each repository language.
Family Detail Tab
Use the Family Detail tab (tabs pane; current table must be the main table of a repository that contains a Families table) to view (but not to edit) the family data of the family to which the record selected in the Records pane belongs. The tab contains a two-column grid listing the fields of the Families table (the family fields) and their corresponding values.
Figure 12: Family Detail Tab
Validations Tab
Use the Validations tab (tabs pane) to add, rename, delete and duplicate user-defined validations, and to view and edit validation properties. The Validations tab contains a multi-object properties grid that consists of two subpanes: (1) the Validations pane, which lists the user-defined validations; and (2) the Properties pane, which lists the set of properties for each user-defined validation.
Figure 13: Validations Tab
Assignments Tab
Use the Assignments tab (tab pane) to add, rename, delete and duplicate user-defined assignments, and to view and edit assignment properties. The
subpanes: (1) the Assignments pane, which lists the user-defined assignments; and (2) the Properties pane, which lists the set of properties for each user-defined assignment.
Figure 14: Assignments Tab
Workflows Tab
Use the Workflows tab (tabs pane) to view and process workflow tasks. The Workflows tab consists of two subpanes: (1) the Status pane, which contains the list of task statuses; and (2) the Tasks pane, which contains a grid that lists the tasks for the currently selected queue.
Figure 15: Workflows Tab
Search Selections Tab
The Search Selections tab (tabs pane) lists all of the search selections that are currently in effect.
Web Tab
The Web tab (tab in bottom-right pane) contains an embedded browser that displays the results of the currently configured URL against any MDM record data passed as parameters within the URL.
Status Bar
The Status bar displays the following mode-specific information for the current table (from left to right):
• “n selected” (when zero or two or more records are selected)
• “x of y records found” (where ‘y’ is the total number of records, and ‘x’ is the number of records displayed in the Records pane based on the current search selections)
• “Record Mode”
Special Columns of Record Mode
In addition to displaying a column for each field in a record, the Records pane has several special columns that indicate the record’s state.
• [Protected] column. Indicates whether each record has been protected from editing and deletion using the Protect command. MDM uses the lock icon ( ) as the name of the column in the Records grid and in the column of values. (All tables.)
• [Checked Out] column. Indicates whether each record has been checked out using the Check In/Out commands. MDM uses the checked out icon ( ) as the name of the column in the Records grid and in the column of values. (Main table only.)
• [Done] column. Indicates whether each record has been marked as done ( ) for the current workflow task by the assignee user. Appears only when the workflow task is selected in the Workflows tab. (All tables.)
• Validation Result columns. Indicate whether each record has succeeded ( ) or failed ( ) the most recently run validation or set of validations. MDM uses the name of the validation in square brackets as the name of the column in the Records grid. (All tables.)
• Approval Result columns. Indicate whether each record has been approved ( ) or disapproved ( ) by the approvers of an Approve step in a workflow. MDM uses the name of the approver in square brackets as the name of the column in the Records grid. (All tables.)
• Matching Result columns. Indicate the count, maximum level, and maximum total score among potential matching records in the Records grid, and the level and individual scores for each rule for each record in the Matches grid. (Matching mode; main table only.)
Searching for Records
When you want to locate a particular record or set of related records in the database, you perform a search. This allows you to view and manipulate a subset of records that match your search selections.
Most master data management systems use DBMS-style query forms to initiate a search and locate specific records. Users start with nothing and often end up with nothing, blindly typing in values as though looking for a needle in a haystack! By contrast, the MDM system features two search options: free form, which mirrors the traditional query approach, and a powerful and efficient search capability called drilldown search . Drilldown search allows users to start with all of the items in the repository and then effortlessly zoom in on items of interest.
Drill Down Search
Figure 18: Drill Down Search
MDM’s drilldown search has the following features:
• Pick lists. All possible values are always displayed in pick lists from which one or more values can be selected, so the user doesn’t need to type in values, nor have any prior knowledge of the contents and structure of the MDM repository.
• Dynamic limiting. Pick lists are continuously updated to include only values that are currently valid based on the previous selections, so the user can never go down a dead-end path, and never gets the message “No matches found!” • Intuitive. Pick lists make drilldown search intuitive, easy to use, and very,
very fast, allowing the user to search the entire repository and locate any item or group of items in seconds, narrowing down from even millions of items to one or several with just a few mouse clicks.
• Multidimensional. Selections can be made simultaneously from among different dimensions (such as category, manufacturer, attributes, and keyword), selections can be made in any order, and selections made in one dimension automatically limit the valid choices for every other dimension. • Interactive. Users can add – or remove – selections in each dimension one at
a time, to narrow down – or expand – the search results progressively. And there is no “Search” button, so intermediate search results are immediately updated and always displayed after each selection.
With drilldown search, you can search via lookup fields, attributes or qualifiers of a qualified table record. You can make search selections in any order to constrain the search results, or remove search selections in any order, to expand the set of search results.
At each step along the way, the system narrows down the choice of available search values to show only those that are valid for the current result set (based on the previous search selections). This is known as limiting and guarantees that you can never go down a dead-end path. For example, if you select “Chain Saws” in the Category tab as your first search option, and then open the Manufacturer tab,
only the manufacturers of chain saws will be listed. The result is an extremely flexible and powerful search capability, delivered through an exceptionally smooth and intuitive process.
Hint: Limiting makes it easy to detect errors in your master data, when
values that should not be part of the search results show up in the limited list of existing field or attribute values.
Drill Down Searches
So, drilldown search:
• Starts with all the products selected.
• Lets you interactively browse and sort the entire record set. • Lists allowable values for each of the search parameters.
• Does not require that you know in advance what you’re looking for. • Allows you to add one constraint at a time to narrow the search. • Executes the search immediately as each constraint is added. • Allows you to remove constraints to expand the search.
Further, each time you select a value in a drilldown search, MDM immediately does all of the following:
• Provides a count of the number of records found.
• Limits the record set to only those that match the constraints. • Limits the list of values in every other search dimension.
• Lets you interactively browse and sort intermediate search results. • If the selection was a category field, lists the attributes that apply to that
category.
• If the selection was a qualified lookup field, lists the qualifiers that apply to that qualified table record.
• If the selection was a tuple field, offers the set of flat lookup, hierarchy lookup, and Boolean member fields and values.
Note: For drilldown search, each flat, hierarchy, taxonomy, and qualified
lookup field in the current table automatically appears as a search tab in the Search Parameters pane in Record mode, as described in the following sections; each contains the limited set of values for the current result set based on previous search selections
Note: Drilldown search is not currently supported for Lookup [Main]
fields and so no search tabs appear for these fields in the Search Parameter pane. You can instead perform free-form searches on the Lookup [Main] fields in your tables,
Flat and Hierarchy Lookup Search Tabs
If the search tab corresponds to a flat or hierarchy lookup field, the tab includes a list (in the case of a flat lookup field), or a tree (in the case of a hierarchy lookup field)
Figure 19: Flat Lookup Search Tab
Hint: Flat and hierarchy lookup search tabs permit you to select multiple
values.
Note: When you select a node in a hierarchy lookup search tab the entire
branch (that node and all of its descendents) is selected to give the visual cue that what you are really doing is selecting leaf node values (since records can only be set to the value of leaf nodes). Moreover, the selected descendents include those that are limited out of the selection tree due to other search field selections or because no record in the repository has the final leaf value set. In this way, the selections remain constant even as the other search selections change, or as records are assigned to leaf values.
Taxonomy Lookup Search Tabs
If the search tab corresponds to a taxonomy lookup field (e.g. Category), the tab is split into three subpanes. The top subpane contains the hierarchy of category field values. The bottom left Attributes subpane lists the attributes linked to the selected category (or all the attributes, if no category has been selected), and the bottom right Values subpane contains the list of values for the selected attribute.
