• No results found

R ELATIONSHIPS T ABLE

In document MDM Console Reference Guide (Page 82-88)

MDM Table Types

R ELATIONSHIPS T ABLE

The Relationships table is a special table with a predefined set of fields, and records that that appear in the top-right Relationships pane of MDM Console. Each record that you add in 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 MDM Console, you specify the related products and/or non-products for each record in MDM Data Manager

TIP ►► You can add, modify, and delete product relationships just like the fields of a normal table.

NOTE ►► When you first create a new MDM repository, MDM automatically creates the Relationships table.

The properties for each relationship are listed in Table 14; all of the properties applicable to each type are directly editable in the Relationship Detail pane.

Table 14. Relationship Properties Property Description

Position (Pos.) The display order of the relationship within the table ([n]).

Name The relationship name.

Code The relationship code.

Type

The relationship type:

 Parent/Child

 Sibling

Name Is

For Parent/Child relationships, what the Name applies to:

 Parent

 Child

Name 2 The second name for Parent/Child relationships.

Has Position The child has a position value associated with it (Yes/No)?

Has Required The record has a required value associated with it (Yes/No)?

Has Quantity The record has a quantity value associated with it (Yes/No)?

Parent Table The parent table for a Parent/Child relationship.

Child Table The child table for a Parent/Child relationship.

NOTE ►► Not all of the properties apply to all relationship types;

however, all of them appear as columns in the Relationships grid.

MDM Console Reference Guide 83 Relationship Types

Each type of MDM relationship corresponds to a real-world relationship between product records and/or non-product records, as summarized in Table 15 and described in the following sections.

Table 15. Relationship Types

Type Table(s) Examples

Sibling Main  Cross-sells (related products)

 Interchange products (all equivalent)

Parent/Child

 Interchange products (one preferred)

Main/Subtable  Kits and parts (“SKU of non-SKUs”)

 Cross-reference part numbers

Subtable/Main  Bundles (“non-SKU of SKUs”)

 Interchange product groups

Subtable/Subtable  Parts and subparts (“kits of kits”)

 Bill of materials

Subtable1/Subtable2  Interchange part number groups

NOTE ►► The tables of a parent/child relationship can be of type Main, Flat, Hierarchy, or Qualified (but not of type Taxonomy).

NOTE ►► An interchange is an alternate product that can be substituted for a given product, both of which are main table product records in the MDM repository. If the interchange product records are all completely equivalent, use a sibling product relationship to represent this information; if one of the group of interchange products is the “preferred” product, use a parent/child relationship. By contrast, a cross-reference is an alternate part number for a given product that can be used to find the main table product record but that is not itself a product record; use a parent/child relationship (main/subtable) to represent this information. (When the cross-reference part numbers come from a known set of alternate sources, you can instead use a qualified table to represent this information, which improves the ability to search by the cross reference part number information.)

NOTE ►► Category-level relationships are defined within MDM Data Manager in Taxonomy mode using matching sets.

84 MDM Console Reference Guide NOTE ►► Product-level relationships can be used to store not only relationships between products but also between products and other records of additional information, establishing the traditional one-to-many relationship between main table records and subtable records.

(See “Lookup and Non-Lookup Subtables – A Comparison” on page 70 for a discussion of alternative MDM repository structures.)

Sibling vs. Parent/Child Relationships

MDM supports two basic types of product-level relationships:

Sibling. A sibling relationship relates a group of main table product records that are equivalent and/or interchangeable from some merchandising or structural standpoint.

NOTE ►► Sibling relationships are symmetric. In other words, if A, B, and C are in a single group of related sibling records, then A is related to its siblings B and C, B is related to its siblings A and C, and C is related to its siblings A and B.

Parent/child. A parent/child relationship relates a group of records that are not equivalent, where one of them is the parent, and the rest of them are the children.

NOTE ►► Parent/child relationships are asymmetric. In other words, if A, B, and C are in a group of related parent/child records and A is the parent of B and C, then B is the child of A and the sibling of C, and C is the child of A and the sibling of B.

Examples of sibling relationships include “cross-sells” and “interchange products.” Examples of parent/child relationships include “assemblies and components” and “kits and parts.”

Figure 24 illustrates both a sibling “cross-sells” relationship and an

“assemblies and components” parent/child relationship.

Products:

SKU Name 101 Computer System 202 Monitor 203 Logitech Keyboard 204 Microsoft Mouse 301 Intel CPU 302 256MB Memory 303 40 GB Hard Disk 105 Laser Printer

Figure 24. Sibling and parent/child relationships

Assembly and components (parent/child) Cross-sells

(sibling)

MDM Console Reference Guide 85 NOTE ►► The siblings in a sibling relationship are like the sibling children in a parent/child relationship; the sibling relationship itself is like a parent/child relationship without the parent.

NOTE ►► In the figure above, there could also be a third relationship called “Products and Accessories” to store more cross-sell information.

Single- vs. Multi-Table Relationships

A sibling relationship always relates main table product records. By contrast, a parent/child relationship can relate records within a single table or between any two tables. Specifically, it can relate: (1) records within the products of the main table (e.g. “products and accessories”);

(2) between product records of the main table and non-product records of a subtable in either direction (e.g. “kits and parts” [mainsubtable] or

“bundles and products” [subtablemain]); (3) records within the non-products of a single subtable (e.g. “parts and subparts”); or (4) between non-product records of one subtable and non-product records of a different subtable (e.g. “interchange part number groups”).

Figure 25 illustrates two parent/child relationships between tables: a

“bundles and products” relationship and a “kits and parts” relationship.

Products:

Bundles: SKU Name

Id Name 101 Washer Parts:

101 Bundle 1 202 Dryer Part No Name

202 Bundle 2 203 Refrigerator 101-01 Drawer

203 Bundle 3 204 Freezer 102-02 Shelf

301 Stove 103-03 Icetray

105 Microwave 204-04 Drum

Figure 25. Two different parent/child relationships

NOTE ►► From a relationship-centric standpoint, a parent/child relationship represents a single relationship among a set of related records. By contrast, from a product-centric standpoint, a parent/child relationship within a single table (e.g. main/main or subtable/subtable) in effect represents two distinct relationships for each record: (1) the

“parent” relationship of the parent/child relationship in which the record is the parent (looking “down” at its children); and (2) the “child”

relationship of the parent/child relationship in which the record is one of the children (looking “up” at its parent).

86 MDM Console Reference Guide Single- vs. Multi-Level Relationships

A parent/child relationship that relates records between two different tables (e.g. main/subtable, subtable/main, or subtable1/subtable2) is automatically a single-level relationship, in that you can traverse at most once from a parent in one table to its children in the other table.

By contrast, a parent/child relationship within a single table (e.g.

main/main or subtable/subtable) can be multi-level, in that you can recursively traverse from a parent to its children, from a child to its children, and so on.

For example, for an “assembly and components” parent/child

relationship within the main table of product records, a parent assembly record can be related to child component records, while a component that is itself an assembly becomes a parent that can be further related to child subcomponent records. Similarly, for a “parts and subparts”

parent/child relationship within a subtable of parts records, a parent part record can be related to child subpart records, and then further related to subparts of the subparts.

Hybrid Relationships

The sibling and parent/child relationship types described above are the full set of product-level relationships explicitly supported by MDM.

However, if a relationship embodies both sibling and parent/child data, and/or the parent/child data relates records both within the main table and between the main table and one or more subtables, you can create multiple independent product relationships to store the data, and then combine them at the presentation layer into a hybrid relationship.

In this way, individual relationships act as building blocks that can be combined into complex hybrid relationships to represent many different multi-dimensional relationships between product records and/or non-product records, and can be navigated in a variety of ways.

For example, an “interchange” sibling relationship can be combined with a “cross-reference” parent/child relationship (main/subtable) to

represent all of the different SKUs and part numbers that can be used to identify and locate a particular product or group of products.

NOTE ►► Alternatively, if the same set of cross-reference part numbers always applies to each of the interchange products, then you can eliminate the need to maintain cross-reference part numbers individually for each product by replacing the sibling and parent/child relationships above with two parent/child relationships from a subtable of interchange groups (really, a “super-table”) to: (1) the main table (the “interchange product groups” relationship); and (2) the part number subtable (the “interchange part number groups” relationship).

MDM Console Reference Guide 87 Relationship Qualifiers

A product-level relationship allows you to store any of three additional pieces of information about each related sibling or child record:

Position. The record’s position in the sequence (parent/child only).

Required. Whether or not the record is required (Yes/No).

Quantity. The quantity of the record (defaults to 1).

88 MDM Console Reference Guide

In document MDM Console Reference Guide (Page 82-88)