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.
