T UPLES AND E XISTING MDM S TRUCTURES

MDM has historically included many different data modeling structures, each of which was well-suited and optimized for a different set of data modeling challenges.

Each structure had its own particular – and often unique – properties and semantics around definition, data entry, navigation, and search.

And each was relatively rigid and suffered from both a lack of generality and various limitations on when it could be used.

By contrast, the tuple data structure is a basic building block that subsumes, completely generalizes, and dramatically enhances these structures, as summarized in Table 20 and more fully described in the following sections.

Table 20. Tuples vs. Existing MDM Structures

Capability Tuples Qualified Parent/Child Hierarchy Tables Hierarchical main table entity •

Include qualified information • •

Qualify reference to any table •

Reference records of same table • • •

Reference records of different table • • •

Multi-level nesting • • •

Bidirectional navigation • •

Bidirectional visibility • •

NOTE ►► Since the unique capabilities of each existing structure cannot be mixed-and-matched, users were often forced to compromise by choosing an imperfect “best fit” for each data modeling challenge.

96 MDM Console Reference Guide Qualified Lookups

A qualified lookup allows you to reference the records of a qualified lookup table, and also to further “qualify” the reference by storing additional link-specific information in fields known as qualifiers.

By contrast, including the lookup to what would previously have been the qualified lookup table among the fields of a tuple rather than adding qualifiers to the definition of the lookup table allows you to:

• Extend to all lookup tables the specialized qualifier support previously offered only by qualified lookup tables.

• Create a qualified reference to any normal lookup table, not just one explicitly and already defined as a qualified lookup table.

• Share the lookup table among different referencing tuple fields, each with a different set of qualifiers.

Finally, in the degenerate case of no applicable table of lookup records, a tuple without lookups can store a set of nested “link-specific” records without forcing the data modeler to create a “phantom” lookup table containing a single record and a single non-qualifier field.

NOTE ►► Tuples generalize the concept of qualified lookup tables (e.g. qualified lookup  qualified anything). And whereas qualified lookup tables support just a single level of nesting, tuples support arbitrarily deep multi-level nesting (see “Tuples“ on page 99 for more information).

Parent/Child Relationships

Parent/child relationships are extremely flexible and allow you to store references between records of any tables. Like a lookup without pick-list search and data entry, they support several unique features:

• References to records of the same table in addition to those of another table.

• References to main and other non-lookup subtables that contain a very large number of records.

• Nested multi-level relationships of arbitrary depth in addition to single-level relationships.

• Bidirectional navigation both from the parent to the child and from the child to the parent.

• Bidirectional visibility of the relationship both from the parent record and from the child record.

NOTE ►► Despite their flexibility, relationships are hard to navigate and impossible to search, and can only be qualified with optional Required and Quantity fields rather than an arbitrary set of qualifiers.

MDM Console Reference Guide 97 By contrast, including one or more lookups into the same or another table among the fields of a tuple provides an alternative for modeling parent/child relationships, and allows you to include link-specific

“qualified” information on every pair of related records.

NOTE ►► Tuples are an alternative to parent/child relationships that add full qualifier support but do not offer the bidirectional navigation nor bidirectional relationship visibility offered by parent/child relationships.

Hierarchical Main Table Entities

Recall that hierarchy tables within MDM allow you to create parent/child relationships between the records of a single lookup table, and then to create a single- or multi-valued lookup into that table.

However, hierarchy tables offer only limited support for trees rather than arbitrary hierarchies, with specialized and limited semantics (e.g. single parent; no cycles), parent/child relationships only between the same type of entity, and no ability to store link-specific information.

And most importantly, hierarchy tables provide support only for hierarchy lookups rather than for hierarchical main table entities.

By contrast, MDM tuples allow you to model flexible hierarchies and networks, complementing hierarchy lookups and tables with generalized support for hierarchical main table entities.

Specifically, by including one or more lookups into the same or another table among the fields of a tuple, you can express composite and arbitrarily complex relationships between similar and dissimilar business entities and also attach link-specific “qualified” information to every set of related records.

NOTE ►► Tuples generalize the concept of hierarchy management (trees  fully qualified hierarchies and networks) and extend support for hierarchy lookups to support for hierarchical main table entities.

NOTE ►► You can use either of two alternative approaches to modeling a hierarchy: (1) include a tuple with a lookup within the primary record (e.g. Org Chart); or (2) create a separate “links” table with multiple lookups and other fields (e.g. BOM).

NOTE ►► Tuples offer generalized hierarchy support only from a data storage perspective. However, the specialized hierarchy semantics, functionality, and behavior (e.g. visual UI materialization, tree-view navigation, hierarchy manipulation, import and export) are NYI.

98 MDM Console Reference Guide