Communities
A collaborative platform to connect and grow with like-minded Informaticans across the globe
Product Communities
Connect and collaborate with Informatica experts and champions
Discussions
Have a question? Start a Discussion and get immediate answers you are looking for
User Groups
Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
Get Started
Community Guidelines
Knowledge Center
Troubleshooting documents, product guides, how to videos, best practices, and more
Knowledge Base
One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
Support TV
Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
Documentation
Information library of the latest product documents
Velocity (Best Practices)
Best practices and use cases from the Implementation team
Learn
Rich resources to help you leverage full capabilities of our products
Trainings
Role-based training programs for the best ROI
Certifications
Get certified on Informatica products. Free, Foundation, or Professional
Product Learning Paths
Free and unlimited modules based on your expertise level and journey
Resources
Library of content to help you leverage the best of Informatica products
Tech Tuesdays Webinars
Most popular webinars on product architecture, best practices, and more
Product Availability Matrix
Product Availability Matrix statements of Informatica products
SupportFlash
Monthly support newsletter
Support Documents
Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
Product Lifecycle
End of Life statements of Informatica products
Ideas
Events
Change Request Tracking
Marketplace
English
  • Multidomain MDM 10.4
  • All Products

Table of Contents

Search

  1. Preface
  2. Part 1: Introduction
  3. Part 2: Configuring Hub Console Tools
  4. Part 3: Building the Data Model
  5. Part 4: Configuring the Data Flow
  6. Part 5: Executing Informatica MDM Hub Processes
  7. Part 6: Configuring Application Access
  8. Appendix A: MDM Hub Properties
  9. Appendix B: Viewing Configuration Details
  10. Appendix C: Row-level Locking
  11. Appendix D: MDM Hub Logging
  12. Appendix E: Table Partitioning
  13. Appendix F: Collecting MDM Environment Information with the Product Usage Toolkit
  14. Appendix G: Informatica Platform Staging
  15. Appendix H: Informatica Platform Mapping Examples
  16. Appendix I: Glossary

Configuration Guide

Configuration Guide

Back Next

Types of Tables in an Operational Reference Store

Types of Tables in an Operational Reference Store

An
Operational Reference Store
 contains tables that you configure and system support tables.

Configurable Tables

You can use the configurable tables to model business reference data. You must explicitly create and configure these tables.
The following table describes the types of MDM Hub tables that you can configure:  
Type of Table
Description
Base object
Used to store data for a central business entity, such as customer, product, or employee, or a lookup table such as country or state. In a base object, you can consolidate data from multiple source systems and use trust settings to determine the most reliable value of each base object cell. You can define one-to-many relationships between base objects. You need to create and configure the base objects.
Landing table
Used to receive batch loads from a source system. You need to create and configure the landing tables.
Staging table
Used to load data into a base object. You define mappings between landing tables and staging tables to specify how data must be cleansed and standardized when it is moved from a landing table to a staging table. You need to create and configure the staging tables.

Infrastructure Tables

The MDM Hub infrastructure tables manage and support the flow of data in the
Hub Store
. The MDM Hub creates, configures, and maintains the MDM Hub infrastructure tables whenever you configure base objects.
The following table describes the types of MDM Hub infrastructure tables:
Type of Table
Description
Cross-reference table
Used to track the origin of each record in the base object.
Cross-reference tables are named according to the following pattern:
C_<base object name>_XREF
where <base object name> is the root name of the base object. For example, if the base object name is PARTY, the cross-reference table name is C_PARTY_XREF. When you create a base object, the MDM Hub creates a cross-reference table to store information about data that comes from source systems.
History table
Used if history is enabled for a base object.
History tables are named according to the following pattern:
  • C_<base object name>_HIST. Base object history table.
  • C_<base object name>_HXRF. Cross-reference history table.
where <base object name> is the root name of the base object. For example, a base object named PARTY has the C_PARTY_HIST and the C_PARTY_HXRF history tables.
The MDM Hub creates and maintains different types of history tables. The history tables provide detailed change tracking options, including merge and unmerge history, history of the pre-cleansed data, history of base objects, and the cross-reference history.
Match key table
Contains the match keys that the MDM Hub generates for all base object records. The match key tables are named according to the following pattern:
C_<base object name>_STRP
where <base object name> is the root name of the base object. For example, if the base object name is PARTY, the match key table name is C_PARTY_STRP.
Match table
Contains the pairs of matched records in the base object resulting from the execution of the match process on the base object. The match tables are named according to the following pattern:
C_<base object name>_MTCH
where <base object name> is the root name of the base object. For example, if the base object name is PARTY, the match table name is C_PARTY_MTCH.
External match table
Contains the data for external match jobs. You can use the following types of external match tables:
  • EMI table. External match input table. Contains records to match against the records in the base object.
  • EMO table. External match output table. Contains the output data for External Match jobs. Each row in the EMO table represents a pair of matched records. One of the pairs of records is from the EMI table and one is from the base object.
The external match tables are named according to the following pattern:
  • C_<base object name>_EMI
  • C_<base object name>_EMO
where <base object name> is the root name of the base object. For example, if the base object name is PARTY, the match table names are C_PARTY_EMI and C_PARTY_EMO.
Temporary tables
The MDM Hub creates temporary tables that it needs to process data during batch jobs. After the MDM Hub completes processing data, the batch processes remove the temporary tables because they are no longer needed. If the batch process, application server, or the database server fails, temporary tables may not be deleted.
Temporary tables have the prefix T$_. After the batch process completes, if the repository contains temporary tables that the batch process created, you can manually remove them. Some temporary tables do not have the prefix T$_ prefix. For example, the cleanse temporary table has the suffix _CL instead, and the delta temporary table has the _DLT suffix instead.

Supported Relationships Among Data

The MDM Hub supports one:many and many:many relationships between tables, in addition to hierarchical relationships between records in the same base object. In the MDM Hub, you can define relationships between records in multiple ways.
The following image shows the different relationships between base objects:
An example showing an foreign key relationhip between base objects, a many to many relationship between base objects, and a parent-child base object relationship.
The following table describes relationship types between data:
Type of Relationship
Description
Foreign key relationship between base objects
One base object, the child table, contains a foreign key column with values that match the values in the primary key column of another base object, the parent table.
Records within the same base object
Within a base object, records are related to each other hierarchically. You can define many-to-many relationships within the base object.
After you configure the relationships in the
Hub Console
, you can use the relationships to configure match column rules by defining match paths between records.
0 COMMENTS
We’d like to hear from you!