A traditional SQLDBMS stores data in the records and fields (rows and columns) of a collectionof flat database tables. All tables have the same rectangular structure inSQL. A SQL database is relational because of the relationships set up betweenthe different tables.
In an relationalDBMS (RDBMS), information about a single record can be combined from multipletables by relating values in matching columns. This helps to eliminateredundant data; beyond that, however, an RDBMS does not support any additionalstructuring of the data itself.
By contrast, theMDM system supports a variety of different table types that are specificallysuited 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 areinherently non-relational), as shown in the following table.
TableType
Description
Main table and subtables
Flat
Main table orsubtable. A flat table has the standard, rectangular SQL structure consistingof records and fields (rows and columns). The main table of an MDM repositoryis always a flat table.
Hierarchy
Subtable. Ahierarchy table organizes information in a hierarchy, where each record isrelated to a parent record (even if the only parent is the root) and may alsobe related to sibling records and/or child records. The main table in an MDMrepository typically contains some fields whose data may be hierarchical innature. For example, a Manufacturer field may need to accommodate division andsubdivision information for manufacturers. This hierarchical information isstored in a separate, hierarchy subtable associated with the Manufacturerlookup field in the main table. Most of the hierarchy tables used in an MDMrepository contain lookup information for fields in the main table. Otherhierarchy tables in MDM include taxonomy tables, the Masks table, and theFamilies table, described below. MDM supports hierarchies with an unlimitednumber of parent/child levels.
Note that ahierarchy table is useful even when it is flat (i.e. only leaf nodes below theroot), because it stores the ordered sequence of sibling records, allowing youto override the unordered sequence of values in a flat table and instead putthe values in a fixed order.
Taxonomy
Subtable. Ataxonomy is the classification scheme that defines the categories andsubcategories that apply to a collection of records. Categorizing recordsenables you to isolate subsets of records for various organizing, searching,editing and publishing purposes.
A taxonomy table inMDM stores a hierarchy of categories and subcategories and also supportsattributes, “subfields” that apply to particular categories ratherthan to the entire collection of records. MDM supports multiple simultaneoustaxonomies.
Qualified
Subtable. Aqualified table in MDM stores a set of lookup records, and also supportsqualifiers, “subfields” that apply not to the qualified tablerecord by itself, but rather to each association of a qualified table recordwith a main table record. MDM supports multiple simultaneous qualifiedtables.
Qualified tablescan be used to support product applications and application-based search, andalso to store any large set of subtable records that contain fields whosevalues are different for each main table record, such as multiple prices fordifferent quantities, divisions, regions, or trading partners, cross-referencepart numbers, and additional distributor/supplier/customer-specificinformation for different distributors, suppliers, or customers.
Object tables
Images
A single tablenamed Images. Stores image files, where each imageis stored as a record in the table.
Text Blocks
A single tablenamed Text Blocks. Stores blocks of text, whereeach text block is stored as a record in the table.
Copy Blocks
A single tablenamed Copy Blocks. Stores blocks of textinterpreted as copy, where each text block is stored as a record in thetable.
Text HTMLs
A single tablenamed Text HTMLs. Stores blocks of textinterpreted as HTML, where each text block is stored as a record in thetable.
PDFs
A single tablenamed PDFs. Stores PDF files, where each PDF isstored as a record in the table.
Sounds
A single tablenamed Sounds. Stores sound files, where each soundfile is stored as a record in the table.
Videos
A single tablenamed Videos. Stores video files, where each videofile is stored as a record in the table.
Binary Objects
A single tablenamed Binary Objects.Stores other binary object files, where each binary object file is stored as arecord in the table.
Special tables
Masks
A single hierarchytable named Masks. In concept, a mask acts like astencil, in that it blocks (“masks”) all main table records fromview except the defined subset of records that are included in the mask, toallow the subset to be viewed and manipulated as a whole. A mask is a staticsnapshot of the set of records that are included in the mask (as opposed to aview or a named search, where the results set is determined dynamically everytime the search is run). Each record in the Maskstable is the name of a subset of main table records. MDM supports an unlimitedhierarchy of masks.
Named Searches
A single flat tablenamed Named Searches. A named search is a staticsnapshot of the search selections that were in effect when the named searchwas saved (as opposed to a mask, which is a snapshot of the subset ofrecords), where the results set itself is determined dynamically when it isselected. Each record in the Named Searches tablereturns a subset of main table records. MDMsupports 400 named searches per repository.
Families
A single hierarchytable named Families. Used to further partitionmain table records in each category into smaller groups based upon the valuesof other fields and/or attributes. You can associate family data (a paragraph,an image, bullets) once with a family of products rather than with eachindividual product, and also define the table layout of the field and/orattribute data (field order; stack, vertical, and horizontal pivots; and otherdisplay options). This table is available only in Family mode.
Image Variants
(Does not appearanywhere in the MDM Client)
A single tablenamed Image Variants. Used to define the structureand format of each of the variants for each image. Each variant is a modifiedversion 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 MDMClient.
Relationships
(Does not appearanywhere in the MDM Client)
A single tablenamed Relationships. Used to define each of thedifferent record-level relationships. Each relationship can be eitherbidirectional (sibling) or unidirectional (parent-child). This table ismanaged in the MDM Console and is not visible in the MDM Client, although therelationships between records can themselves be created and edited in Recordmode.
Workflows
A single tablenamed Workflows. Stores the workflows of an MDMrepository, where each workflow is stored as a record in the table. Workflowsare created and edited in the MDM Client.
Data Groups
A single hierarchytable named Data Groups. Stores the hierarchy ofdata groups used to break the entire set of objects in the MDM repository intomanageable subgroups.
Validation Groups
A single hierarchytable named Validation Groups. Stores thehierarchy of validation groups used to organize multiple validations forsubsequent execution as a group.
System tables
Roles
(Does not appearanywhere in the MDM Client)
A single table named Roles. One of three tables used to implement MDM repositorysecurity and access control. Each role can selectively grant or deny access toany MDM function and to any table or field. This table is managed in the MDMConsole.
Users
(Does not appearanywhere in the MDM Client)
A single tablenamed Users. One of three tables used to implementMDM repository security and access control. Each user can have one or moreroles. This table is managed in the MDM Console.
Logins
(Does not appearanywhere in the MDM Client)
A single tablenamed Logins. One of three tables used toimplement MDM repository security and access control. Contains an entry foreach currently connected MDM client application, which can be terminated bythe MDM Console user.
Change Tracking
(Does not appearanywhere in the MDM Client)
A single tablenamed Change Tracking. Allows you to specify thefields for which adds, modifies, and deletes should be tracked and stored inthe Change Tracking table.
Remote Systems
(Does not appearanywhere in the MDM Client)
A single tablenamed Remote Systems. Used to define the differentremote systems for import and export. Each remote system specifies whether itsupports import only, export only, or both.
Ports
(Does not appearanywhere in the MDM Client)
A single tablenamed Ports. Used to encapsulate the logisticaland configuration info for inbound and outbound processing of MDM data, forconsolidation and distribution respectively.
URLs
(Does not appearanywhere in the MDM Client)
A single tablenamed URLs. Used to specify the URLs that can beused as the target of an embedded browser in the Web tab in the MDMClient.
XML Schemas
(Does not appearanywhere in the MDM Client)
A single tablenamed XML Schemas. Used to identify the XMLschemas for import and syndication. Each XML schema is the name of an.xsd file.
Reports
(Does not appearanywhere in the MDM Client)
A single tablenamed Reports. Contains an entry for each reportfile generated by the various MDM repository operations, which can be accessedand viewed by the MDM Console user.
Logs
(Does not appearanywhere in the MDM Client)
A single tablenamed Logs. Contains an entry for the log filesgenerated by the MDM Server, which can be accessed and viewed by the MDMConsole user.
For properorganization of the records within an MDM repository, a hierarchy or taxonomylookup field can normally be assigned only to the value of a leaf node in thehierarchy. For more information, see Inner Node Assignmentsand Internal Leaf Nodes.
