Table of Contents


  1. Introduction
  2. Configuring Hub Console Tools
  3. Building the Data Model
  4. Configuring the Data Flow
  5. Executing Informatica MDM Hub Processes
  6. Configuring Application Access
  7. MDM Hub Properties
  8. Viewing Configuration Details
  9. Search with Solr
  10. Row-level Locking
  11. MDM Hub Logging
  12. Table Partitioning
  13. Collecting MDM Environment Information with the Product Usage Toolkit
  14. Glossary

Considerations for Using Delta Detection

Considerations for Using Delta Detection

When you use delta detection, you must consider certain issues.
Consider the following issues:
  • Delta detection can be done either by comparing entire records or via a date column. Delta detection on last update date is the most efficient, as
    Informatica MDM Hub
    can simply compare the last update date columns for each incoming record against the record’s previous last update date.
  • With Delta detection you have the option to not include the column in landing table that is mapped to the last_update_date column in the staging table for delta detection.
    If you do include the last_update_date column when you set up Delta Detection, and the only thing that changes is the last_update_date column, the
    MDM Hub
    will do lots unnecessary work in delta detection and load work.
  • When processing records by last update date, do not use the Now cleanse function to compare last update values (for example, testing whether the last update date in a source record occurred before the current system date). Using Now in this way can produce unpredictable results.
  • Perform delta detection only on columns for those sources where the Last Update Date is not a true indicator of change. The
    Informatica MDM Hub
    stage job will compare the entire source record against the most recent corresponding record in the PRL (previous load) table. If any cell is different, then the record is passed on to the staging table. Delta detection is being done from the PRL table.
  • If the delta detection is based on a date column (last_update_date, system-defined date column, or custom-defined date column, such as DOB), then only the record with the later date value in the date column (in comparison to the corresponding record in the PRL table, not the max date in the RAW table) will be inserted into the staging table.
  • If the delta detection is based on specific columns, including date columns (such as DOB and last_update_date), then records with any change to the date values in the specified columns (in comparison to the corresponding record in the PRL table, not the max date in the RAW table) will be inserted into the staging table.
  • During delta detection, when you are checking for deltas on all columns, only records that have null primary keys are rejected. This is expected behavior. Any other records that fail the delta process are rejected on subsequent stage processes.
  • When delta detection is based on the Last Update Date, any changes to the last update date or the primary key will be detected. Updates to any values that are not the last update date or part of the concatenated primary key will not be detected.
  • Duplicate primary keys are not considered during subsequent stage processes when using delta detection by mapped columns.
  • Reject handling allows you to:
    - View all reject records for a given staging table regarding of the batch job
    - View all reject records by day across all staging tables
    - Query reject tables based on query filters


We’d like to hear from you!