TAXONOMIES

 

A taxonomy is a general term for classification scheme. The purpose of

a taxonomy is to group like things together into categories, usually

based on a set of common, category-specific characteristics, or

attributes.

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,” as shown in Figure 2.

MDM REPOSITORY STRUCTURE

 

A thorough understanding of the table and data types at your disposal is

essential for properly creating and maintaining MDM repositories. This

section provides an introduction to these concepts, which will be

addressed again later in this guide.

An MDM repository consists of the following tables:

• 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 then

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.

26

MDMConsole

What is an MDM Repository?

• Subtables. 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, 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 assigned to the value of the

corresponding lookup field in the main table.

DATA INTEGRITY ►► Lookup subtables are just one of the powerful

ways that MDM enforces data integrity in an MDM repository. The set

of legal 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.

DATA INTEGRITY ►► Object tables eliminate redundant information,

since each object appears only once in the MDM repository even if it is

linked to multiple records.

NOTE ►► When you first create a new MDM repository, MDM

automatically creates the single instance of each object table.

NOTE ►► 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.

NOTE ►► The Data Groups and Validation Groups tables do not

appear anywhere in MDM Console.

MDM Console

27

Part 1: Basic Concepts

• 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.

NOTE ►► 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.

What is an MDM Repository?

 

What is an MDM repository? The incorrect or at best incomplete answer

is often that a master data repository is simply a database, and also

since a SQL-based RDBMS is often used for managing master data.

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 is also a sales tool, which

lists the products offered for sale by a vendor and allows 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. So

a published catalog is also about creating and reinforcing a corporate

image.

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 should 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.

MDM Console

Part 1: Basic Concepts

• Product families. A printed catalog of product information provides

an excellent model for how information on groups of records within

an MDM repository of product information should be organized into

product families (also called units, presentations, or modules), which

further partition the products in each category into smaller groups of

products based upon the values of other fields and/or attributes. In

addition to the individual products that comprise the family, a product

family includes the 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. As a sales tool, a published catalog of

product information requires the wide variety of product relationships

that are essential for effective selling. 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 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.

NOTE ►► See “The Master Data Import Server” on page 237 for

more information about MDIS.

NOTE ►► See “The Master Data Syndication Server” on page 261 for

more information about MDSS.

NOTE ►► See the MDM Publisher Reference Guide for more

information about MDLS.

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 clients across a network.

The various components of an MDM software environment, and how
they interact with the MDM Server; are described below and illustrated in Figure 1.

• 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.